Project vision
Background
The customer, RedRiver, has seen a need for an easy-to-use and secure application for smartphones and tablets which facilitates text and image chat between two or more users, as well as live video calls.
RedRiver is a company that works in providing consulting in the .NET-framework and C#. They offer their customers help with web development, system development and project management in web and system development projects.
Problem description
RedRiver wants a simple and secure chat application that is able to be used for example as an internal communication solution by their customers.
The problem they see with today's chat applications is that they are overly complicated and affect people with little or no prior experience of IT in the way that they are not able to use them for communication. A solution would be a chat application targeted towards these people, with a self-explanatory and accessible user interface, so that they too can make use of text and image chat as well as live video calls to communicate internally in the organisation or with family and friends.
Additionally, the introduction of data laws such as GDPR place stringent requirements on data contractors and processors regarding data handling, storage, erasure and general consent. Against this background our customer has requested an application which combats the perceived usability shortcomings of the current generation of chat applications and takes into account the forthcoming data requirements.
User/target group
The application is aimed at RedRiver's customers in the public sector and larger corporations that have a need for a communication application with high requirements on security and accessibility. The application is primarily intended to be used as an internal communication solution for RedRiver's customers. Users who have little prior experience of dealing with computers or mobile devices should be able to use the application without problems.
Market
Given RedRiver's security and accessibility requirements, the application should be suitable for internal communication in the public sector and larger corporations. The application should, for example, be able to be used within the medical sector for secure communication between doctor and patient. Security critical sectors are therefore included in the target market segments.
Base features
- The application should work on smartphones and tablets.
- The GUI should be easy to understand and use (designed according to WCAG 2.1, level AA).
- Users should be able to create chat rooms to send text messages and images to each other. Users should also be able to make video calls to each other.
- Users should be able to add other users as friends.
- The entire system (i.e. client, server, storage and data transmission between these elements) should be secure. The system should be stable and resistant to virus and malignant code attacks.
Similar/competing systems
There are a number of similar chat applications. The primary competing systems are Skype and Google Hangouts, but applications such as Discord, Slack and Twitch also incorporate many of the features requested by the client. An analysis of these systems can be found in 2.1 Analysis of competing systems.
Analysis of competing systems
Skype
Skype is a free-to-use application that a user can use for text, voice and video chats in a group or only with one other person. With Skype, you can keep in touch with friends and family, hold a meeting, work with colleagues and other things that requires face-to-face communication. Skype is available on desktop, mobile, tablet, xbox and wearable devices. For a fee a user can also make phone calls and send texts. Skype has the feature to add friends.
Google Hangouts
Google Hangouts is a free-to-use application available on desktop, iOS and Android devices. To be able to start a video call the user has to have a Google account and a computer, mobile or tablet with a microphone and camera. Google Hangouts offers messaging through text, images and gifs, video calls for up to ten people, voice calls to other Hangout-users and voice calls to phones for a fee. Google Hangouts has the feature to add friends, but also to distribute a link to make a chat available to people without Google accounts.
Discord
Discord is a free-to-use text and voice chat application targeted towards gamers and presents itself as an easier-to-use alternative to Skype and TeamSpeak. Discord is available on desktop and mobile devices and has over 87 million users. Discord has features like friends list, the ability for users to have multiple channels, direct messaging and low latency on the voice chat.
Slack
Slack is a cloud-based set of proprietary team collaboration tools and services. It has three pricing-levels; free-to-use, standard and plus. Slack has features like text, voice and video calls, and depending on what pricing-level one is at the voice and video calls are either for one-to-one and up to 15 participants. The application is primarily used by businesses to connect their teams.
Twitch
Twitch is a free-to-use application where people can livestream games, their craft projects, IRL adventures and so on. Every user account has their own channel with a unique URL that can be shared to anyone and the channel is automatically listed in a category for what is being livestreamed at that very moment. If a channel for example is streaming the game Dead By Daylight, the channel shows up when a user searches for channels streaming that particular game. A streamer can set a title on their stream, a tag for what they are streaming, tags for if they are part of any communities or teams. This is to make it easier for viewers to find them when using the search function. Channels can be followed and subscribed to, and with the help of third-party tools also be donated to. Each channel has their own chat where viewers and the streamer can send text messages and emojis to each other. Other features for users on Twitch are friends list, private messaging, user settings and settings concerning the livestream video.
Project plan
Project name
RedRiver chat application. Project name is to be decided.
Customer
RedRiver
Mattias Djupdahl, info@redcode.se.
Telephone: 0733 400 407
Marco Villegas, marco.villegas@redcode.se.
Telephone: 0706880589
RedRiver is a company that works in providing consulting in the .NET-framework and C#. They offer their customers help with web development, system development and project management in web and system development projects.
Contractor
Project manager is a role that will be passed around with every new phase.
Andrew Galbraith
Role: Customer contact and requirements manager, project manager during construction.
Email: ag222hu@student.lnu.se.
Github: andygalb.
Jimmy Bengtsson
Role: Technical manager, project manager during transition.
Email: jb223pu@student.lnu.se.
Github: jimmybengtsson.
Linda Ott Olander
Role: Customer contact and requirements manager, project manager during elaboration.
Email: lo222hd@student.lnu.se.
Github: LindaOtt.
Sofia Kristiansen
Role: Test manager, project manager during inception.
Email: sk222uf@student.lnu.se.
Github: ProfessorPotatis.
Background
The project is part of the Linneaus university course 1DV611 - Software development project in a group - and made in association with the company RedRiver. RedRiver wants to have a chat application developed for mobile and tablet devices where two or more users can send text messages and pictures to one another. They wish the graphical user interface to be easy to understand and use, since the application is targeted towards a user group where some may have little or no prior experience with IT and chat applications. Base features for the application can be found in the project vision.
Purpose
The purpose is to work on a project with a real world customer and to solve their provided problem, in this case to develop a chat application for mobile and tablet devices. As the project is to be conducted in a group, the purpose is also to gain experience in discussing different types of solutions to the problem and to use the knowledge we've gained throughout our studies and put them to practical use.
Overall goals
The course goals is for the students to:
- Follow a standardised model for software development and conduct a project in a group.
- Write and continuously update the project documentation.
- Critically examine other projects and their documentation.
- Present the group's method and results both in written and oral form in a way adapted to the user group.
The project's overall goals is to:
- Continuously throughout the project interact with the customer
- Continuously make deliveries of the system to the customer.
- In iterations develop and deliver an application according to the customer RedRiver's requirements.
Base features for the application can be found in the project vision. All requirements can be found in the product backlog.
Resources
Here you'll find the resources available in the project.
Time: 720 hours.
People: 4.
Technology: Technical documentation.
Method for system development: Combination of Unified Process and SCRUM. Weekly iteration plans and tutor meetings. Customer meetings at least every second week.
Delivery
During every customer meeting we do a delivery of the system. Together with the customer we go through the application and get feedback on what is good and what should be worked on. The customer also mentions what features are most important to them, and what general feeling they get from the application so far.
Time plan
Presented here are the project milestones and their hard deadlines. The milestones are broken into each phase that they belong to according to the course homepage "Projektuppgifter". A hard deadline is when something has to be done, but the milestones should preferably be done well before the deadline.
Inception phase
Iteration 0
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M1 | Get the project up and running; customer meeting, create wiki documentation etc. | Done | 23 Mars |
Deliverables: Wiki-page documentation.
Iteration 1
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M2 | Create vision and product backlog based on customer meeting, continue work with other documentation | Done | 30 Mars |
Deliverables: Wiki-page documentation, Google docs product backlog.
Iteration 2
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M3 | Fulfill inception major milestone | Done | 6 April |
Deliverables: Proof of concepts for SignalR and WebRTC. A signed vision document. The inception documentation.
Elaboration phase
Iteration 3
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M4 | Deliver F1, F2, F3, F4 prototypes, proof of concepts and the system thus far to the customer | Done | 12 April |
Deliverables: Visual prototypes for the requirements F1, F2, F3, F4. Proof of concepts. Preliminary software architecture.
Iteration 4
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M5 | Deliver F1, F2, F3 front end design | Done | 20 April |
Deliverables: F1, F2, F3 front end design.
Iteration 5
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M6 | Deliver F1, F2, F3, F4 full functionality to customer. The system should pass all tests, manual and with Jest/Postman. Fulfill elaboration major milestone | Done | 26 April |
Deliverables: F1, F2, F3, F4 full functionality and system should pass all tests.
Construction phase
Iteration 6
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M7 | F5,F6 basic functionality implemented on both client and server | Started | 4 May |
Deliverables: F5,F6 basic functionality, although this will require additional testing and refinement.
Iteration 7
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M8 | F5,F6 basic functionality implemented on both client and server | Started | 11 May |
Deliverables: F5,F6 basic functionality, although this will require additional testing and refinement.
Iteration 8
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M9 | F5,F6,F13 fully implemented on client and server | Started | 18 May |
Deliverables: F5,F6,F9 fully implemented and tested, WCAG 2.1 compliance analysed.
Transition phase
Iteration 9
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M10 | Final acceptance test completed and approved by customer | Not started | 25 May |
Deliverables: .
Iteration 10
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M11 | Project presentation | Not started | 10:00-12:00, 30 May |
| M12 | Documentation completed | Not started | 1 or 8 June |
Deliverables: .
Iteration 11
| Milestone | Description | Status | Deadline |
|---|---|---|---|
| M13 | Final delivery to customer | Not started | 1 or 8 June |
| M14 | Examination, deadline for submission | Not started | 12 June |
Deliverables: .
Approximation
At this moment it is difficult to do a size approximation of the project, such as lines of code, classes, use cases or number of functions. The current requirements are still subject for change due to client communication and time restrictions.
Communication plan
The main communication is done through our own Slack-channel since everyone in the group is taking this course off campus.
We will have weekly group meetings using Slack calls. Time for these meetings are decided in the group Slack-channel.
We will have weekly tutor meetings with Tobias Ohlsson using Slack calls. These are held every tuesday at 9:00.
Additional group meetings can be decided in the group Slack-channel.
Communication with the customer is done on a weekly basis through emails and by weekly or bi-weekly Google Hangouts. These Google Hangouts are booked via email correspondence with the customer.
Project organisation
Roles
Customer: RedRiver.
Tutor: Tobias Ohlsson.
Project manager: Alternating every new phase.
Inception project manager: Sofia Kristiansen.
Elaboration project manager: Linda Ott Olander.
Construction project manager: Andrew Galbraith.
Transition project manager: Jimmy Bengtsson.
Customer contact and requirements manager: Andrew Galbraith and Linda Ott Olander.
Technical manager: Jimmy Bengtsson.
Test manager: Sofia Kristiansen.
Version control
Version control for our Google Docs sheet product backlog can be found in the wiki product backlog.
Version control for our source code in the Github repo can be found in the Github repo README.md.
Product backlog
The requirements have been divided into the FURPS+ model categories. For the requirements where it's applicable we use short user stories to describe the requirement. In other cases we use "The system shall...". The requirements in each category are prioritized based on the value for the product and how difficult they might be to implement.
In our iteration plans the individual requirements will be refered to with the ID they've got here in the product backlog.
Example: F1 refers to the first requirement in the Functionality category.
Google Docs
We have a Google Docs sheet for our product backlog so that all members of the group can do changes in the same document simultaneously. Having the product backlog as a Google Docs makes it easier for us to comment and prioritize the requirements. The product backlog is then transferred to our wiki product backlog once a week or at least in the end of every phase of the project (inception, elaboration, construction, transition). The transfer is done by downloading the Google document as a webpage (HTML), opening the HTML-files in an IDE and copy the tables. The copied tables are then converted from an HTML-table to a markdown-table using markdownTables.
New in Google Docs (as of 16th of April)
In our Google Docs product backlog, in the Functionality category, we have re-prioritized the basic requirements for the application. We and the customer decided that we should focus on requirements that are critical for the regular user of the application. Therefore some requirements, that previously were listed with the other functional requirements, are listed under "In terms of time" and can be seen as bonus features.
The priority number goes from number one to five, with five being the highest priority. In addition to putting high priority on the requirements that are critical for the regular user, we have also focused on risk and dependencies. The requirements that are the most basic for the application to work, i.e. the ones with the highest risk, have the highest priority. If one requirement is dependent on another, the requirement with dependees needs to be implemented first, and therefore has a higher priority number.
Functionality
| ID | Name | Description/User story | Dependencies | Status | Priority | Author | Test case | Test case Author |
|---|---|---|---|---|---|---|---|---|
| F1 | User register | A user must be able to register to the app. | - | Implemented | 5 | Linda/Sofia | T.1.1, T.1.2, T.1.3, T.1.4, T.1.5 | Sofia |
| F2 | User login | A user must be able to login to the app. | F1 | Implemented | 5 | Sofia | T.2.1, T.2.2, T.2.3, T.2.4, T.2.5,T.2.6 | Sofia |
| F3 | User - own data access | A user should have access to their own personal information. | F1, F2 | Implemented | 5 | Andrew | T.3.1 | Sofia |
| F4 | Add friends | A user should be able to add friends to a friendslist. | F1, F2 | Implemented | 5 | Sofia | T.4.1, T.4.2, T.4.3, T.4.4, T.4.5 | Sofia |
| F5 | User chat room | A user should be able to create chat rooms to which other users can connect. | F1, F2 | Started | 5 | Linda | - | - |
| F6 | User text message | A user can send text messages to other users. | F1, F2 | Started | 5 | Andrew | T.6.1, T.6.2 | Linda |
| F7 | Logs through UI | The communication log is available to the user through the app’s UI. | F1, F2 | Not implemented | 5 | Andrew | - | - |
| F8 | User camera photo message | A user can take a picture with the device camera and send it to other users. | F1, F2 | Not implemented | 4 | Andrew | - | - |
| F9 | User stored image message | A user can choose an image stored on the device and send it to other users. | F1, F2 | Not implemented | 4 | Andrew | - | - |
| F10 | User video call | A user can call another user and communicate with video. | F1, F2 | Not implemented | 4 | Andrew | - | - |
| F11 | User support | The user can contact admin via the UI for support. | F1, F2 | Not implemented | 4 | Linda | - | - |
| F12 | Admin/user chat | The admin can chat with users. | F1, F2 | Not implemented | 4 | Linda | - | - |
| F13 | Consent Mail | Before a user begins using the app, the user receives a mail with a link. Clicking upon the link allows the user to consent to use the app. | F1 | Not implemented | 4 | Andrew | - | - |
| F14 | User consent withdrawal | The user can at any time withdraw their consent via the app’s UI. | F1, F2 | Not implemented | 4 | Andrew | - | - |
| F15 | Consent withdrawal message | If consent is withdrawn, the user receives a message confirming that the user will be removed from the system and that all records of communication will be removed. | F1, F14 | Not implemented | 4 | Andrew | - | - |
| F16 | Consent withdrawal confirmation | When the user receives such a message, the user can confirm removal from system. | F1, F14, F15 | Not implemented | 4 | Andrew | - | - |
| F17 | User removal upon consent withdrawal | If consent is withdrawn, the user is removed from the system within 24 hours. | F1, F14, F15, F16 | Not implemented | 4 | Andrew | - | - |
| F18 | User data removal upon consent withdrawal | If consent is withdrawn, all records of communication are removed from the system. Including the chat logs of other users where the user has participated. | F1, F14, F15, F16, F17 | Not implemented | 4 | Andrew | - | - |
| F19 | User account inactivation | It should be possible for a user’s account to be inactivated (unclear if the user can do this or admin or both?) | F1 | Not implemented | 3 | Andrew | - | - |
| F20 | User account deletion | It should be possible for a user’s account to be terminated (unclear if user does this or admin or both) | F1 | Not implemented | 3 | Andrew | - | - |
| F21 | Log erasure notification | The user is advised upon signup that logs will be erased after a period of time. | F1 | Not implemented | 3 | Linda | - | - |
| F22 | Log storage time | Logs should not be stored for a longer period of time than required by law. | F1 | Not implemented | 3 | Andrew | - | - |
| F23 | Registered relative | Each user should have a registered relative | F1 | Not implemented | 2 | Linda | - | - |
| F24 | Registered relative can withdraw consent | The registered relative should be able to withdraw consent on behalf of the user | F1 | Not implemented | 2 | Linda | - | - |
| F25 | Registered relative can erase users account | The registered relative should be able to erase the users account | F1 | Not implemented | 2 | Linda | - | - |
| F26 | User channel creation | A user can create a channel and send live from her/his camera. | F1, F2 | Not implemented | 1 | Andrew | - | - |
| F27 | User channel invite | A user can invite other users to watch the channel by copying a link and distribute that link to the viewers. | F1, F2, F26 | Not implemented | 1 | Andrew | - | - |
Usability
| ID | Name | Description/User story | Dependencies | Status | Priority | Author | Test case | Test case author |
|---|---|---|---|---|---|---|---|---|
| U1 | Simple UI | The application should have a clear and simple user interface. | - | Started | 5 | Andrew | - | - |
| U2 | WCAG 2.1 | The design should be in accordance with WCAG 2.1 - minimum level AA, better if possible. | - | Not implemented | 5 | Andrew | - | - |
| U3 | UI buttons | The user interface should make use of well-defined buttons based on available actions – for instance writing a new message, taking or uploading a photo, starting a video conversation. | - | Started | 4.75 | Andrew | - | - |
| U4 | Responsive | The UI is reponsive and works on mobile and tablet devices. | - | Started | 4.5 | Andrew | - | - |
| U5 | App accessibility | The app should be accessible for all users with access to the internet regardless of the device being Android or iOS. | U1 | Not implemented | 4.5 | Andrew | - | - |
| U6 | UI extents | The full extent of the user interface should be utilized by the user’s ongoing communication. | - | Not implemented | 4 | Andrew | - | - |
Reliability
| ID | Name | Description/User story | Dependencies | Status | Priority | Author | Test case | Test case author |
|---|---|---|---|---|---|---|---|---|
| R1 | Environment | The app should work on smartphones and tablets. | - | Started | 5 | Andrew | - | - |
| R2 | Harmful code | The system should be protected from harmful code, specifically OWASP Top 10. | S1 | Not implemented | 4.75 | Sofia | - | - |
| R3 | Consistency | The app should have consistent functionality across all operating systems and environments. | - | Started | 4.5 | Andrew | - | - |
| R4 | Encrypted text on server | All text information stored on server, such as communication logs and personal data, should be encrypted. | - | Not implemented | 4.5 | Linda | - | - |
| R5 | Secure text on server | All text information stored on server, such as communication logs and personal data, should be protected from access by third parties. | - | Not implemented | 4.5 | Linda | - | - |
| R6 | Secure communication | Communication should take place securely, so that no third party can access transmitted data. | - | Not implemented | 4.25 | Andrew | - | - |
| R7 | Secure image storage | Images should be stored securely so that no third party has access to them. | - | Not implemented | 4 | Andrew | - | - |
| R8 | Virus protection | The system should be protected from viruses - OWASP Top 10 mentioned by customer. | S1 | Not implemented | 4 | Andrew | - | - |
| R9 | Limited client data storage | As little data as possible should be stored on clients in order to prevent unwarranted spreading of pictures, films and other information. | - | Not implemented | 3.5 | Andrew | - | - |
| R10 | System backup | All information on system should be backed up in a second location so that it can be restored in case the data in the first location is compromised | - | Not implemented | 3 | Andrew | - | - |
Performance
| ID | Name | Description/User story | Dependencies | Status | Priority | Author | Test case | Test case author |
|---|---|---|---|---|---|---|---|---|
| P1 | Stress tolerance | The system should accommodate at least 100 simultaneous users (both solely logged in and active) without noticeable detriment to the systems functionality, accessibility or usability. | - | Not implemented | 4 | Andrew | - | - |
Supportability
| ID | Name | Description/User story | Dependencies | Status | Priority | Author | Test case | Test case author |
|---|---|---|---|---|---|---|---|---|
| S1 | System protection updates | The system's protection against viruses and harmful code can be updated | R2,R8 | Not implemented | 3 | Andrew | - | - |
Risk list
In this document we present the risks that might affect the outcome of our project. By listing the risks we are made aware of what consequences they may have and how we can handle them so that they do not have to happen in the first place, or to mitigate the consequences caused by them. This is a document that will be updated throughout the project when new risks are detected.
The table we are using for the risks uses nine columns with information that should be provided to make the risks more clear.
- ID - Unique ID.
- Name - A short name for the risk.
- Description - Describes the risk.
- Likelihood - How likely it is for the risk to happen. 1 being low, 5 being high.
- Consequence - The consequence the risk has for the project. 1 being low consequences, 5 being high consequences.
- Priority - Likelihood * Consequence. A high number equals high priority, a low number equals low priority.
- Coverage strategy - How can we monitor this risk, who is responsible?
- Consequence strategy - Can we in some way mitigate the consequence for the risk?
- Likelihood strategy - Can we in some way reduce the likelihood for the risk to happen?
Old risks that have been taken care of should be down prioritized and new risks should be added continuously.
| ID | Name | Description | Likelihood | Consequence | Priority | Coverage Strategy | Consequence Strategy | Likelihood Strategy |
|---|---|---|---|---|---|---|---|---|
| 1 | Time estimation | Too optimistic time estimation for different tasks leads to tasks getting pushed to next iteration | 4 | 3 | 12 | Weekly meetings, everyone needs to be on the same page. Project manager is responsible | Prioritize tasks, so that the highest prioritized tasks get done first | Iteration plans where tasks gets prioritized and signed off by the group |
| 2 | Unrealistic expectations | Customer can have expectations, leading to a determination of failure despite the project meeting its goal and objectives. | 3 | 3 | 9 | Team involves customer in development to receive feedback. | Manage customer expectations. | Clear requirements definition. |
| 3 | Vague requirements | Vaguely specified requirements can be more time-consuming than expected | 3 | 3 | 9 | Constant communication with costumer to ensure that everyone understands the requirements. | Make sure the requirements are clear so development doesn't take longer then expected. | Involve customer in the progress of development. |
| 4 | Testing | Unit testing with Jest can be complicated when using React Router and other imported components. | 3 | 3 | 9 | Use StaticRouter or MemoryRouter to create mockups of Routes. Link | Check for alternative solutions. | Check for alternative solutions. |
| 5 | Customer Contact | Inadequate communication with the customer | 2 | 4 | 8 | Andrew initiates contact with customer | Regular customer contact and deliveries to ensure desired product development | - |
| 6 | Design/User interface | User interface doesn't fulfill desired requirements for target group etc. | 2 | 4 | 8 | Team needs to be aware of different standards and techniques used in the project. | Develop a UI that is easy to understand and navigate as the customer wishes. Constant delivery to customer and process received feedback. | Follow WCAG 2.1, level AA. |
| 7 | Dependence on external supplied components | Component has unwanted hidden dependencies which might create maintainability issues for the group and later for the customer. | 2 | 4 | 8 | Document all dependencies on imported components/modules. | Do not import npm-modules that aren't well maintained. | Check for alternative components/modules if actual module has many dependencies |
| 8 | Requirements Inflation | As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten timelines | 2 | 3 | 6 | Weekly contact with customer through emails or meetings where current progress is presented | Constant involvement of customer and developers | Constant involvement of customers and developers where changes and new requirements are included in following iterations |
| 9 | New techniques | Techniques that no one in the group has any knowledge of is needed to implement some requirements. | 2 | 3 | 6 | Investigate and learn techniques that is new for the group. | Use techniques that the group has experience of. | Check for alternative techniques if lack of knowledge. |
| 10 | Personnel turnover | Key personnel leave the project taking critical information with them that delays the project | 1 | 4 | 4 | - | Increased collaboration and information sharing on the team | Make sure team members share key information. Pair-programming, Comments in code, Naming convention. All group members have maximum access rights to repos and cloud environments. |
| 11 | SignalR/ASP.NET version | ASP.NET Core 2 is newly released and the SignalR client for this version is still in alpha. | 1 | 4 | 4 | A working POC has been created, proving that this risk should have a low priority | Check for alternative frameworks or consider pure websockets implementation | The SignalR client will become production ready, since it is backed by Microsoft. |
| 12 | WebRTC | WebRTC is needed for video calls and live streaming. Uncertain if WebRTC can be used from server to client for live-broadcast. | 1 | 4 | 4 | Create PoC for video calls and live streaming. | Check for alternative frameworks | WebRTC video call PoC is implemented so probably it will also work with live streaming. |
| 13 | Development environment | Different OS etc. can lead to various results during development | 1 | 4 | 4 | Setup Vagrant or Docker if use of different OS. Jimmy | Together decide what development environment to use in the project | Use vagrant or docker. Team use same OS. |
| 14 | Poor communication in team | Poor communication between team-members can lead to rework and reduced productivity | 1 | 4 | 4 | Each team-member report on planned work in slack every morning. Ask team for advice when uncertain. Team prioritize and distribute tasks together. | - | Use Slack to communicate in team. |
| 15 | Gold plating | Unnecessary features are added. | 2 | 2 | 4 | Team needs to be aware of the requirements and together decide what to do. | Strict adherence to requirements definition. | Stick to the prioritized requirements. |
| 16 | Insufficient or ineffective testing | Test are insufficient; many post-delivery defects might be reported | 1 | 3 | 3 | Do manual testing and create unit tests while implementation of requirements | Make sure all features of a requirement are tested before merging branch with master | Unit test as much as possible |
Test specification
This document specifies how testing is going to be carried out in the project. The document contains a test plan where the testing tools and testing strategy is presented. The document also contains test suites where the test cases are presented.
Overall testing goal
The overall goal with the testing is to achieve 100 percent functionality coverage. This is to make sure that the system fulfills the customer's requirements and works as expected by the end-delivery. Our goal is to at least carry out one test on every part of the system, whether it being automated, explorative, negative or other.
Automated and manual testing should be done on a weekly basis to catch bugs early.
Test plan
Testing tools
For the automatic tests the following tools will be utilized. When an automated test is done; take a print screen and paste it into the test report.
React.js front-end
- Test framework Jest.
- Code coverage and test reports. In the terminal: npm test. (Same as jest --coverage -u)
ASP.NET backend
- Test framework nUnit, Postman.
Stress tests
- Load testing tool jMeter.
Testing strategy
| Level | Approach | Type | Run test |
|---|---|---|---|
| Unit | Automated testning, negative testning | Automated | In the terminal: npm test |
| Integration | Automated testning, negative testning | Automated | In the terminal: npm test |
| System | Explorative testning, user tests | Manual | Manual |
| Acceptance | Test cases | Manual | Manual |
Levels
Testing will be carried out on different levels; unit, integration, system and acceptance.
- On unit level a smaller part of the source code is tested. A unit is a function or a method.
- On integration level already tested units are tested together to see if the parts work together.
- On system level the whole application is tested in its entirety.
- On acceptance level the software is verified against the customers requirements.
Approach
Testing will be carried out in different ways; automated, negative, explorative, user tests and test cases.
- Automated testing: In the automated tests the test code is written with the testing tools listed above. This will mainly be done to test that the functions work as expected.
- Negative testing: Like the automated tests, the test code for negative testing is written with the testing tools listed above. In these tests we will use improper in-data to get error messages. By doing this we can then see that the right error message is shown at the right time. For example an expected 404 should not be a 403.
- Explorative testing: In explorative testing the tester gets to use the system and keep a log over the steps taken throughout the system. If and when something unexpected happens this will be logged by the tester so that the developer knows where there might be faulty code or bugs hiding.
- User tests: The user tests let the final user test the system. Problems and comments are documented and used to evaluate the usability.
- Test cases: The test cases are written based on the requirements in the product backlog. They are used to test that the system has the expected functionality.
Code coverage
The parts of the application that might not be covered by the automated tests are presented by the code coverage tool Istanbul, that comes with the Jest framework, and the test reports generated from the tool.
Test suites
A test suite is a collection of test cases that tests the same requirement from different angles based on the scenarios that might take place. The test suites will here on after be listed based on the type of test it is; automated or manual. The test suites can be found in their respective subdocument.
6.1. Automated testing
6.2. Manual testing
Automated testing
Automated testing
The automated test suites and test cases are documented with the test code in our Github repo. These tests do not have any detailed test cases written for them since the test code is considered enough documentation.
For automated tests that test specific functionality, the following additional information can be added to get a better overview to what has been tested:
Example:
- Test suite Fx – Register new user
- Test case 1 - Register with correct input
- Test case 2 - Register with existing username
- Test case 3 - Register with too short password
Server
Postman Automated Server API Tests
- Test suite F1 – Register new user
- T1 Account Creation testuser1
- T2 Account Creation missing username
- T3 Account Creation testuser2
- Test suite F2 – Login
- T1 Protected route request w/o auth
- T2 Get JWT Bad User
- T3 Get JWT Existing User
- T4 Protected route with auth
- Test suite F3 – User - own data access
- T1 Get User Info
- T2 GetFriends
- Test suite F4 – User - add friends
- T1 AddFriend user 1-2
- T2 GetFriends
- Test suite F28 – User levels
- T1 Admin protected route w/o admin auth
- T2 Make user admin
- T3 Get JWT
- T4 Admin protected route with auth
Client
Unit tests.
Automated client tests
Manual testing
Manual testing
The manual test suites and test cases are documented here. To provide an easier overview we have split up the test suites and test cases into sub-documents based on if the requirement for example is a functional one or an usability one.
All manual test suites and test cases can be found in their corresponding document listed below.
Test suites
Each test suite will have the following information:
Header - Contains name of the test suite and the requirement it sets out to test.
Scenario - The general scenario.
Preconditions - Anything that is needed for the test suite to be able to get tested.
In data - What in data should be used (put into the application), if any.
Steps - The steps taken to perform the test/tests.
Test cases - How to test the scenario.
Test cases
Each test case will have the following information:
Test ID - The ID of the test case. The test ID is unique for each test case, making it traceable in both planning and testing.
Title - Short description of test.
Expected - What out data do we expect.
Test report
Here you'll find the results from the manual and automated tests carried out on the system. The manual tests are further described in the 6.2. Manual testing document. The automated tests are described in the 6.1. Automated testing document and are documented with the client test code and server test code.
When a bug is detected they should be tracked using the Github repo issues so that everyone in the group knows what needs to be worked on.
| Iteration | Requirements | Type of testing | Date | Test report |
|---|---|---|---|---|
| 4 | - | Automated (Server) | April 17th | April 17th, 12:47 |
| 4 | - | Automated (Client) | April 20th | April 20th, 13:13 |
| 5 | - | Automated (Client) | April 25th | April 25th, 18:09 |
| 5 | F1-F4 | Manual | April 27th | April 27th, 09:04 |
| 6 | F1-F4 | Manual (Regression) | May 1st | May 1st, 09:49 |
| 7 | F5-F7 and F47 | Manual | May 11th | May 11th, 09:36 |
| 9 | F5-F7 and F47 | Manual (Regression) | May 26th | May 26th, 10:10 |
| 10 | F10, F13, F20, U3, U4, U5 | Manual | May 28th | May 28th, 09:16 |
| 10 | F10, F13, F20, U3, U4, U5 | Manual (Regression) | May 29th | May 29th, 13:49 |
| 10 | F1-F4 and F13 | Manual (Regression) | May 30th | May 30th, 20:40 |
| 10 | F5-F7, F10 and F47 | Manual (Regression) | May 31st | May 31st, 08:57 |
| 10 | P1 | Automated (Server) | May 31st | May 31st, 14:40 |
Iteration 4
Here you'll find the tests that we ran during iteration 4.
Automated testing
Server code test, April 17th, 12:47
Tester: Andrew Galbraith
Client code test, April 20th, 13:13
Tester: Sofia Kristiansen
For a more detailed look and a clickable version:
- Clone our GitHub repo.
- Go to documentation/jest-testreports/coverage_2018-04-20/lcov-report.
- Open the index.html in a web browser.
Iteration 5
Here you'll find the tests that we ran during iteration 5.
Automated testing
Client code test, April 25th, 18:09
Tester: Sofia Kristiansen
For a more detailed look and a clickable version:
- Clone our GitHub repo.
- Go to documentation/jest-testreports/coverage_2018-04-25/lcov-report.
- Open the index.html in a web browser.
Manual testing
April 27th, 09:04
Tester: Sofia Kristiansen
Version: 0.1
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 59.0.2
- Chrome 65.0.3325.181
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 41.16299.371.0
- Firefox 59.0.2
iPhone 5s, iOS 11.2.1.
Web browser:
- Safari 11
- Firefox 11.1
- Chrome 66.0.3359.122
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F1 | T.1.1 | Pass/Fail | Mac firefox, chrome, safari AND PC Edge, firefox AND iPhone 5s safari, firefox, chrome: Pass on the registration part, but email with consent and confirmation link is not yet implemented. All devices: Fail when trying to register over http, only works over https. |
| F1 | T.1.2 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Formuläret ej korrekt ifyllt!" is not giving a hint to what went wrong. |
| F1 | T.1.3 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Formuläret ej korrekt ifyllt!" is not giving a hint to what went wrong. |
| F1 | T.1.4 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Något gick fel. Försök igen!" is not giving a hint to what went wrong. |
| F1 | T.1.5 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Formuläret ej korrekt ifyllt!" is not giving a hint to what went wrong. |
| F2 | T.2.1 | Pass/Fail | Mac firefox, chrome AND PC edge, firefox AND iPhone 5s safari, firefox, chrome: Pass on login functionality. Fail that one needs to update the page after login to be able to see the user page. Mac safari: Pass. I am redirected to my user page. All devices: Fail when trying to login over http instead of https, can't login with either test1 or johndoe. |
| F2 | T.2.2 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Formuläret ej korrekt ifyllt!" is not giving a hint to what went wrong. |
| F2 | T.2.3 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Formuläret ej korrekt ifyllt!" is not giving a hint to what went wrong. |
| F2 | T.2.4 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Något gick fel. Försök igen!" is not giving a hint to what went wrong. |
| F2 | T.2.5 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Något gick fel. Försök igen!" is not giving a hint to what went wrong. |
| F2 | T.2.6 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Formuläret ej korrekt ifyllt!" is not giving a hint to what went wrong. |
| F3 | T.3.1 | Pass/Fail | Mac firefox AND PC firefox: Fail, can not click or open the menu in the top right. Mac safari, chrome AND PC Edge AND iPhone 5s safari, firefox, chrome: Pass, without any problems. |
| F4 | T.4.1 | Fail | All devices: Fail, the friend was added instantly instead of sending a friends request for approval by the other user. |
| F4 | T.4.2 | Pass/Fail | All devices: Pass and fail, validation is there but the message "Något gick fel. Försök igen!" is not giving a hint to what went wrong. |
| F4 | T.4.3 | Fail | All devices: Fail, not implemented yet. |
| F4 | T.4.4 | Fail | All devices: Fail, not implemented yet. |
| F4 | T.4.5 | Fail | All devices: Fail, not implemented yet. |
Points of improvement
- Solved The user page after login should have smaller buttons on mobile device for "Mina chattrum", "Mina vänner", "Starta videosamtal" and "Starta livestream", preferably two buttons on one row, so that the user doesn't have to scroll up and down.
- Solved A user can't register or login over http, only over https. When using http in the URL the user should be redirected to https instead.
- Solved A user is able to add themselves as a friend. This should not be possible.
- Solved A user is sometimes able to add the same friend multiple times. The user should get a message that the friend is already a friend or that the friend request has already been sent.
- Solved When trying to surf to urls ending with /login or /register I get an error message stating: "The resource you are looking for has been removed, had its name change, or is temporarily unavailable." This happens on all devices in all browsers.
- Solved All error messages should be more specific as to what went wrong. For example when someone tries to register without putting in a username, the error message should be something like "Användarnamn krävs" or "Du måste skriva in ett användarnamn". When someone tries to add a non-existent user as a friend, the error message should be something like "Användaren finns inte". Make sure to look at the test cases as to what the error messages should be.
- Solved An email with consent and confirmation link should be sent after someone successfully registered.
- Solved After a successful login the user should be automatically redirected to their user page.
- Solved In Firefox on Mac and PC the user is unable to open the menu in the top right corner.
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
The system looks good on all devices it was tested on, no horizontal scrolling was ever necessary. The application has a simple and self-explanatory user interface which the customer is asking for.
The feeling of the system is somewhat shaky, since the majority of the test cases both pass and fail at the same time. The test cases passes because the functionality is there and it is working, but it doesn't have the right error messages, redirecting or is fully implemented yet. Further explanation to why the system feels shaky and what needs to be worked on to get all test cases to pass is stated in the Points of improvement above.
The system feels stable on:
- None of the devices as of now.
The system feels shaky on:
- All devices.
Iteration 6
Manual testing
May 1st, 09:49
Description: Rerun of manual test cases for F1-F4 after bugfixes.
Tester: Sofia Kristiansen
Version: 0.2
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 59.0.2
- Chrome 65.0.3325.181
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 41.16299.371.0
- Firefox 59.0.2
iPhone 5s, iOS 11.2.1.
Web browser:
- Safari 11
- Firefox 11.1
- Chrome 66.0.3359.122
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F1 | T.1.1 | Pass/Fail | All devices: Pass on the registration part, but email with consent and confirmation link is not yet implemented (F13). |
| F1 | T.1.2 | Pass | All devices: Pass, the message "Användarnamnet måste vara ifyllt!" is giving a hint to what went wrong. |
| F1 | T.1.3 | Pass | All devices: Pass,the message "Lösenordet måste vara ifyllt!" is giving a hint to what went wrong. |
| F1 | T.1.4 | Pass | All devices: Pass, the message "Användarnamnet är redan registrerat!" is giving a hint to what went wrong. |
| F1 | T.1.5 | Pass | All devices: Pass, the message "Användarnamnet måste vara ifyllt!" is giving a hint to what went wrong. |
| F2 | T.2.1 | Pass | Mac firefox, chrome AND PC edge, firefox AND iPhone 5s safari, firefox, chrome: Pass, I am redirected to my user page after successful login. |
| F2 | T.2.2 | Pass | All devices: Pass, the message "Användarnamnet måste vara ifyllt!" is giving a hint to what went wrong. |
| F2 | T.2.3 | Pass | All devices: Pass, the message "Lösenordet måste vara ifyllt!" is giving a hint to what went wrong. |
| F2 | T.2.4 | Pass | All devices: Pass, the message "Fel användarnamn eller lösenord!" is giving a hint to what went wrong. |
| F2 | T.2.5 | Pass | All devices: Pass, the message "Fel användarnamn eller lösenord!" is giving a hint to what went wrong. |
| F2 | T.2.6 | Pass | All devices: Pass, the message "Användarnamnet måste vara ifyllt!" is giving a hint to what went wrong. |
| F3 | T.3.1 | Pass | All devices: Pass, without any problems. |
| F4 | T.4.1 | Fail | All devices: Fail, the friend was added instantly instead of sending a friends request for approval by the other user. (Divided into new requirement F46) |
| F4 | T.4.2 | Pass | All devices: Pass, the message "Finns ingen med användarnamnet jaedoe!" is giving a hint to what went wrong. |
| F4 | T.4.3 | Fail | All devices: Fail, not implemented yet. (Divided into new requirement F46) |
| F4 | T.4.4 | Fail | All devices: Fail, not implemented yet. (Divided into new requirement F46) |
| F4 | T.4.5 | Fail | All devices: Fail, not implemented yet. (Divided into new requirement F46) |
Points of improvement
- Solved An email with consent and confirmation link should be sent after someone successfully registered (F13).
- Solved F4 should be fully implemented. (Solution: Approve/Deny friendship is divided into new requirement F46)
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
The feeling of the system is much better than last time it was tested. All bugs are taken care of and the majority of the test cases pass. Further explanation to what needs to be worked on to get all test cases to pass is stated in the Points of improvement above.
The system feels stable on:
- All the devices listed above.
The system feels shaky on:
- None of the above listed devices.
Iteration 7
Manual testing
May 11th, 09:36
Description: Manual test cases for F5-F7 and F47.
Tester: Sofia Kristiansen
Version: 0.2
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 59.0.2
- Chrome 66.0.3359.170
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 41.16299.371.0
- Firefox 59.0.2
iPhone 5s, iOS 11.2.1.
Web browser:
- Safari 11
- Firefox 11.1
- Chrome 66.0.3359.122
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F5 | T.5.1 | Pass | All devices: Pass, but if a user leaves the chat room he/she can't create a new chat room with the same users in it until both users has decided to and left the first chat room. |
| F5 | T.5.2 | Pass/Fail | Mac firefox, chrome, safari, iPhone 5s chrome, firefox, PC firefox, edge: Pass. iPhone 5s safari: Fail, got the impression that the new user was added to the chat but it wasn't. |
| F5 | T.5.3 | Pass/Fail | Mac firefox, chrome, safari, iPhone 5s chrome, firefox, PC firefox, edge: Pass. iPhone 5s safari: Fail, unable to leave chat room. |
| F6 | T.6.1 | Pass/Fail | Mac firefox, chrome, safari, iPhone 5s chrome, firefox, PC firefox, edge: Pass. iPhone 5s safari: Fail, unable to send text messages. |
| F6 | T.6.2 | Pass | All devices: Pass. |
| F7 | T.7.1 | Pass | All devices: Pass, though someone who is later added to a chat can see all previously sent messages. Not sure if feature or bug. |
| F47 | T.47.1 | Pass | Mac firefox, chrome, PC firefox, edge: Pass. Mac safari, iPhone 5s safari, chrome, firefox: Pass on uploading a picture, but when clicking the upload button the popup where to choose a file is opened again. |
| F47 | T.47.2 | Pass | Mac firefox, chrome, safari, iPhone 5s safari, chrome, firefox, PC firefox: Pass, unable to choose a non-image file. PC edge: Pass, able to choose non-image file, but got an error message when doing so: "Den uppladdade filen måste vara av typen JPG eller PNG." |
| F47 | T.47.3 | Pass | All devices: Pass, error message: Formuläret ej korrekt ifyllt! |
| F47 | T.47.4 | Pass | All devices: Pass, error message gives a hint to what went wrong. |
| F47 | T.47.5 | Pass | All devices: Pass, error message gives a hint to what went wrong. |
Points of improvement
- Solved If one already has had a chat room with another user but left that chat, it is not possible to create a new chat room with that same user until that user also has left the chat. However, the user can be added again using the + in the opened chat room.
- Solved When the width of the window was such as the chat rooms being on the left side and the chat on the right side (fullsize browser window on desktop), I was unable to change to a different chat room when I had already clicked on one.
- Not solved When a user is added to an existing chat room he/she has not been a part of before, he/she can see all previuosly sent messages in that chat. Not sure if feature or bug.
- Solved In safari, chrome and firefox on iPhone 5s, the form for uploading a profile picture is wonky. "Välj fil" looks squeezed between "Välj en bild att ladda upp som din profilbild" and the upload-button, and is somewhat aligned to the right.
- Solved In safari on Mac and safari, chrome and firefox on iPhone 5s uploading a profile picture works, but when clicking on the upload-button the popup for choosing a file opens again.
- Solved In the friendslist I am unable to start a chat just by clicking on the chat-symbol next to the friends name.
- Solved I am able to start a chat room with only the logged in user in it. I did not get a message that I need to add a friend before clicking "Starta chatt" in the popup.
- Solved On iPhone 5s in safari I was not able to add a user to an existing chat room.
- Solved On iPhone 5s in safari I was not able to leave a chat room.
- Solved On iPhone 5s in safari I was not able to send a text message in a chat. Clicking on "Skicka" didn't work. Clicking on Return on the keyboard didn't work.
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
The system feels stable on the majority of the devices it was tested on with the exception of iPhone 5s safari, where the chat functionality wasn't working as expected. As a user on iPhone 5s safari I was unable to send text messages, add new people to the chat room and to leave the chat room.
Another thing that wasn't working as expected was the profile picture upload. All devices were able to upload a profile picture, but when clicking the upload button the popup where to choose a file was opened again on Mac safari and iPhone 5s safari, chrome and firefox.
Further explanation to what needs to be worked on to get all test cases to completely pass is stated in the Points of improvement above.
The system feels stable on:
- The majority of the devices listed above with the exception for the device listed below.
The system feels shaky on:
- iPhone 5s safari.
Iteration 9
Manual testing
May 26th, 10:10
Description: Rerun of manual test cases for F5-F7 and F47 after bugfixes.
Tester: Sofia Kristiansen
Version: 0.3
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 60.0
- Chrome 66.0.3359.181
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 42.17134.1.0
- Firefox 60.0
iPhone 5s, iOS 11.2.1.
Web browser:
- Safari 11
- Firefox 11
- Chrome 66
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F5 | T.5.1 | Fail | All devices: Fail. Unable to create new chat room when there are no chat rooms already created. Works as expected when there already are chat rooms created from before. |
| F5 | T.5.2 | Pass | All devices: Pass. |
| F5 | T.5.3 | Pass | All devices: Pass. |
| F6 | T.6.1 | Pass | All devices: Pass. |
| F6 | T.6.2 | Pass | All devices: Pass. |
| F7 | T.7.1 | Pass | All devices: Pass. |
| F47 | T.47.1 | Pass | Mac firefox, chrome, PC firefox, Edge: Pass. Mac safari , iPhone 5s safari, chrome, firefox: Pass on uploading picture. But when clicking "Upload" the browse window opens again. |
| F47 | T.47.2 | Pass | Mac firefox, chrome, PC firefox, Edge: Pass. Mac safari, iPhone 5s safari, chrome, firefox: Pass. But when clicking "Upload" the browse window opens again. |
| F47 | T.47.3 | Pass | All devices: Pass. |
| F47 | T.47.4 | Pass | Mac firefox, chrome, PC firefox, Edge: Pass. Mac safari, iPhone 5s safari, chrome, firefox: Pass. But when clicking "Upload" the browse window opens again. |
| F47 | T.47.5 | Pass | Mac firefox, chrome, PC firefox, Edge: Pass. Mac safari, iPhone 5s safari, chrome, firefox: Pass. But when clicking "Upload" the browse window opens again. |
Points of improvement
- Solved In safari, chrome and firefox on iPhone 5s, the form for uploading a profile picture is wonky. "Välj fil" looks squeezed between "Välj en bild att ladda upp som din profilbild" and the upload-button, and is somewhat aligned to the right.
- Solved In safari on Mac and safari, chrome and firefox on iPhone 5s uploading a profile picture works, but when clicking on the upload-button the popup for choosing a file opens again.
- Solved In the friendslist I am unable to start a chat just by clicking on the chat-symbol next to the friends name.
- Solved Unable to create new chat room when there are no chat rooms already created.
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
The system feels stable on the majority of the devices it was tested on. Only thing that makes it feel unstable is that one is not able to create a chat room with a new user that doesn't have any chat rooms created from before.
Another thing that wasn't working as expected was the profile picture upload. All devices were able to upload a profile picture, but when clicking the upload button the popup where to choose a file was opened again on Mac safari and iPhone 5s safari, chrome and firefox.
Further explanation to what needs to be worked on to get all test cases to completely pass is stated in the Points of improvement above.
The system feels stable on:
- All of the devices listed above, with exception for the creation of new chat rooms not working as expected.
Iteration 10
Manual testing
May 28th, 09:16
Description: Manual test cases for F10, F13, F20, U3, U4, U5.
Tester: Sofia Kristiansen
Version: 0.3
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 60.0
- Chrome 66.0.3359.181
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 42.17134.1.0
- Firefox 60.0
iPhone 5s, iOS 11.2.1.
Web browser:
- Safari 11
- Firefox 11
- Chrome 66
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F10 | T.10.1 | Pass/Fail | Mac firefox, chrome, safari, iPhone 5s safari: Pass. PC edge, firefox: Unable to make call to safari. iPhone 5s chrome, firefox: Unable to make call to safari, chrome, firefox. |
| F10 | T.10.2 | Pass/Fail | Mac firefox, chrome, safari, iPhone 5s safari: Pass. PC edge, firefox: Unable to receive or answer call from safari. iPhone 5s chrome, firefox: Unable to answer call from safari, firefox, chrome. |
| F10 | T.10.3 | Pass | All devices: Pass. |
| F10 | T.10.4 | Pass/Fail | Mac firefox, chrome, safari, PC edge, firefox: Pass. iPhone 5s chrome, firefox: Unable to test. iPhone 5s safari: Able to mute the microphone but not unmute it again. |
| F10 | T.10.5 | Pass/Fail | Mac firefox, chrome, safari, PC firefox: Pass. But if the user on Mac safari hide their camera feed first, then the "blackbox" disappears. PC edge: Unable to hide camera feed. iPhone 5s chrome, firefox: Unable to test. iPhone 5s safari: Able to hide camera feed but not show it again. |
| F10 | T.10.6 | Pass/Fail | Mac firefox, chrome, safari, PC edge, firefox: Pass. iPhone 5s chrome, firefox: Unable to test. iPhone 5s safari: If I muted the microphone or hid the camera feed I was unable to end the video call. |
| F13 | T.13.1 | Pass | All devices: Pass. |
| F13 | T.13.2 | Pass | All devices: Pass. |
| F13 | T.13.3 | Pass | All devices: Pass. |
| F20 | T.20.1 | Fail | Not fully implemented yet |
| F20 | T.20.2 | Fail | Not fully implemented yet |
| U3 | U.3.1 | Pass | All devices: Pass. |
| U3 | U.3.2 | Pass | All devices: Pass. |
| U3 | U.3.3 | Pass | All devices: Pass. |
| U3 | U.3.4 | Fail | Not implemented yet |
| U4 | U.4.1 | Fail | Android phone: Not available in this test run. |
| U4 | U.4.2 | Fail | Android tablet: Not available in this test run. |
| U4 | U.4.3 | Pass/Fail | iPhone 5s safari, chrome, firefox: Pass/Fail. Video call looks wonky in landscape mode. The area for writing a chat message is cramped in landscape mode. The "Ändra lösenord" form is not centered in portrait mode; the text "Bekräfta det nya lösenordet" cuts through the line. iPhone 5s chrome: Login in landscape mode was cramped. |
| U4 | U.4.4 | Pass/Fail | iOS tablet: Not available in this test run. |
| U5 | U.5.1 | Pass/Fail | Android phone: Not available in this test run. |
| U5 | U.5.2 | Pass/Fail | Android tablet: Not available in this test run. |
| U5 | U.5.3 | Pass | iPhone 5s safari, chrome, firefox: Pass. |
| U5 | U.5.4 | Pass/Fail | iOS tablet: Not available in this test run. |
| U5 | U.5.5 | Pass/Fail | Android phone: Not available in this test run. |
| U5 | U.5.6 | Pass/Fail | Android tablet: Not available in this test run. |
| U5 | U.5.7 | Pass | iPhone 5s safari, chrome, firefox: Pass. |
| U5 | U.5.8 | Pass/Fail | iOS tablet: Not available in this test run. |
Points of improvement
- Not solved Unable to make a video call from PC edge and firefox to Mac safari.
- Not solved Unable to make a video call from iPhone 5s chrome and firefox.
- Not solved Unable to receive video calls from safari when using PC edge and firefox.
- Not solved Unable to answer video calls from safari, firefox and chrome when using iPhone 5s chrome and firefox.
- Not solved Unable to unmute the microphone in a video call when using iPhone 5s safari.
- Not solved Unable to hide camera feed in a video call when using PC edge.
- Not solved If the camera feed has been set to hidden, I am unable to show camera feed in a video call when using iPhone 5s safari.
- Not solved When muting the microphone and hiding the camera feed I was unable to end the video call using iPhone 5s safari.
- Not solved When using iPhone 5s safari, chrome or firefox, the video call looks wonky in landscape mode. The user has to scroll down to get to the buttons.
- Not solved When using iPhone 5s safari, chrome or firefox, the area for writing a chat message is cramped in landscape mode. The user is unable to see what is being typed.
- Not solved When using iPhone 5s safari, chrome or firefox, the "Ändra lösenord" form on the settings page is not centered in portrait mode; the text "Bekräfta det nya lösenordet" cuts through the line.
- Not solved When using iPhone 5s chrome, the login page is cramped in landscape mode. Difficult to change textfield, since the keyboard takes up a lot of space.
- Not solved On Mac in Safari, when the user hides their camera feed in a video call the feed is hidden, but the placeholder (black box) doesn't appear as expected.
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
Seeing as there are a lot of improvements to carry out, the system doesn't feel very stable when it comes to video calls. This is however something that we were aware of before running the tests. The video call functionality is only partially implemented and one can therefore expect there to be a lot of bugs.
The majority of the usability requirements passed the tests, with the exception of U.4.3 that needs some more CSS to look as expected.
Further explanation to what needs to be worked on to get all test cases to completely pass is stated in the Points of improvement above.
The system feels stable on:
- Mac firefox, chrome and safari.
The system feels shaky on:
- iPhone 5s safari, chrome and firefox.
- PC edge and firefox.
Manual testning
May 29th, 13.49
Description: Manual test cases for F10, F13, F20, U3, U4, U5.
Tester: Linda Ott Olander
Version: 0.3
[This test report is currently being edited]
Description of the test environment
Galaxy S5 Neo, Android version 6.0.1
Web browser:
- Samsung Internet Version 6.4.10.5
- Firefox 60.0.1
- Chrome 66.0.3359.181
iPad Air, model A1475, iOS 11.3.1
Web browser:
- Safari 11
- Firefox 11.1
- Chrome 66.0.3359.122
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F10 | T.10.1 | Pass/Fail | sTestUser3: Galaxy S5 Neo, Samsung Internet. sTestUser4: iPad Air, Safari Fail. Video call can be started, but camera feed not shown despite given permission. sTestUser3: Galaxy S5 Neo, Firefox. sTestUser4: iPad Air, Safari Fail. sTestUser4 does not show up in list, despite being a friend. sTestUser3: Galaxy S5 Neo, Chrome. sTestUser4: iPad Air, Safari Pass. |
| F10 | T.10.2 | Pass/Fail | sTestUser3: Galaxy S5 Neo, Samsung Internet. sTestUser4: iPad Air, Safari Fail. Video call can be started, but camera feed not shown. sTestUser3: Galaxy S5 Neo, Firefox. sTestUser4: iPad Air, Safari Pass. sTestUser3: Galaxy S5 Neo, Chrome. sTestUser4: iPad Air, Safari Pass. |
| F10 | T.10.3 | Pass/Fail | sTestUser3: Galaxy S5 Neo, Samsung Internet. sTestUser4: iPad Air, Safari Fail. It works to set up a call, but no camera feed is shown. sTestUser3: Galaxy S5 Neo, Firefox. sTestUser4: iPad Air, Safari Fail. sTestUser4 does not show up in list, despite being a friend. sTestUser3: Galaxy S5 Neo, Chrome. sTestUser4: iPad Air, Safari Pass. |
| F10 | T.10.4 | Fail | sTestUser3: Galaxy S5 Neo, Samsung Internet. sTestUser4: iPad Air, Safari Fail. The call is made to sTestUser4, but nothing happens when sTestUser4 tries to answer by clicking on the camera button. sTestUser3: Galaxy S5 Neo, Firefox. sTestUser4: iPad Air, Safari Fail. sTestUser4 does not show up in list, despite being a friend. sTestUser3: Galaxy S5 Neo, Chrome. sTestUser4: iPad Air, Safari Fail. Video call is started, but no microphone icon is shown for sTestUser3. |
| F10 | T.10.5 | Fail | sTestUser3: Galaxy S5 Neo, Samsung Internet. sTestUser4: iPad Air, Safari Fail. The call is made to sTestUser4, but nothing happens when sTestUser4 tries to answer by clicking on the camera button. sTestUser3: Galaxy S5 Neo, Firefox. sTestUser4: iPad Air, Safari Fail. sTestUser4 does not show up in list, despite being a friend. sTestUser3: Galaxy S5 Neo, Chrome. sTestUser4: iPad Air, Safari Fail. Video call is made, but no camera icon is shown for sTestUser3. |
| F10 | T.10.6 | Fail | sTestUser3: Galaxy S5 Neo, Samsung Internet. sTestUser4: iPad Air, Safari Fail. A request for a video call is shown for sTestUser4, but nothing happens when sTestUser4 tries to acccept the call. sTestUser3: Galaxy S5 Neo, Firefox. sTestUser4: iPad Air, Safari Fail. sTestUser4 does not show up in list, despite being a friend. sTestUser3: Galaxy S5 Neo, Chrome. sTestUser4: iPad Air, Safari Fail. No red button is shown for sTestUser3. |
| F13 | T.13.1 | Pass | lindaTest 1: Galaxy S5 Neo, Samsung Internet. Pass. lindaTest3: Galaxy S5 Neo, Firefox. Pass. lindaTest4: Galaxy S5 Neo, Chrome. Pass. lindaTest5: iPad Air, Safari Pass. lindaTest6: iPad Air, Firefox Pass. lindaTest7: iPad Air, Chrome Pass. |
| F13 | T.13.2 | Pass | lindaTest 1: Galaxy S5 Neo, Samsung Internet. Pass. lindaTest3: Galaxy S5 Neo, Firefox. Pass. lindaTest4: Galaxy S5 Neo, Chrome. Pass. lindaTest5: iPad Air, Safari Pass. lindaTest6: iPad Air, Firefox Pass. lindaTest7: iPad Air, Chrome Pass. |
| F13 | T.13.3 | Pass | lindaTest8: Galaxy S5 Neo, Samsung Internet. Pass. lindaTest9: Galaxy S5 Neo, Firefox. Pass. lindaTest10: Galaxy S5 Neo, Chrome. Pass. lindaTest11: iPad Air, Safari Pass. lindaTest12: iPad Air, Firefox Pass. lindaTest13: iPad Air, Chrome Pass. |
| F20 | T.20.1 | Fail | Not fully implemented yet |
| F20 | T.20.2 | Fail | Not fully implemented yet |
| U3 | U.3.1 | Pass | johndoe: Galaxy S5 Neo, Samsung Internet. Pass. johndoe: Galaxy S5 Neo, Firefox. Pass. johndoe: Galaxy S5 Neo, Chrome. Pass. johndoe: iPad Air, Safari Pass. johndoe: iPad Air, Firefox Pass. johndoe: iPad Air, Chrome Pass. |
| U3 | U.3.2 | Pass | johndoe: Galaxy S5 Neo, Samsung Internet. Pass. johndoe: Galaxy S5 Neo, Firefox. Pass. johndoe: Galaxy S5 Neo, Chrome. Pass. johndoe: iPad Air, Safari Pass. johndoe: iPad Air, Firefox Pass. johndoe: iPad Air, Chrome Pass. |
| U3 | U.3.3 | Pass | johndoe: Galaxy S5 Neo, Samsung Internet. Pass. johndoe: Galaxy S5 Neo, Firefox. Pass. johndoe: Galaxy S5 Neo, Chrome. Pass. johndoe: iPad Air, Safari Pass. johndoe: iPad Air, Firefox Pass. johndoe: iPad Air, Chrome Pass. |
| U3 | U.3.4 | Fail | johndoe: Galaxy S5 Neo, Samsung Internet. Fail. No settings page is shown. johndoe: Galaxy S5 Neo, Firefox. Fail. johndoe: Galaxy S5 Neo, Chrome. Fail. johndoe: iPad Air, Safari Fail. johndoe: iPad Air, Firefox Fail. johndoe: iPad Air, Chrome Fail. |
| U4 | U.4.1 | Pass | johndoe: Galaxy S5 Neo, Samsung Internet. Pass. johndoe: Galaxy S5 Neo, Firefox. Pass. johndoe: Galaxy S5 Neo, Chrome. Pass. |
| U4 | U.4.2 | ? | No android tablet available. |
| U4 | U.4.3 | ? | No iOS phone available. |
| U4 | U.4.4 | Pass | johndoe: iPad Air, Safari Pass. johndoe: iPad Air, Firefox Pass. johndoe: iPad Air, Chrome Pass. |
| U5 | U.5.1 | Pass | johndoe: Galaxy S5 Neo, Samsung Internet. Pass. johndoe: Galaxy S5 Neo, Firefox. Pass. johndoe: Galaxy S5 Neo, Chrome. Pass. (In landscape mode, the "Remove friend" link in the detailed Friend view overlaps underlying functionality, making it difficult to click those buttons.) |
| U5 | U.5.2 | ? | No android tablet available. |
| U5 | U.5.3 | ? | No iOS phone available. |
| U5 | U.5.4 | Pass/Fail | johndoe: iPad Air, Safari Pass. johndoe: iPad Air, Firefox Fail. When clicking on "start video", only a blank white screen is shown. johndoe: iPad Air, Chrome Fail. When clicking on "start video", only a blank white screen is shown. |
| U5 | U.5.5 | Fail | johndoe: Galaxy S5 Neo, Samsung Internet. Fail. Unable to reach any pages, just loading icon is shown. johndoe: Galaxy S5 Neo, Firefox. Fail. "Something went wrong" message is shown. johndoe: Galaxy S5 Neo, Chrome. Fail. "You are offline" browser message is shown. |
| U5 | U.5.6 | ? | No android tablet available. |
| U5 | U.5.7 | ? | No iOS phone available. |
| U5 | U.5.8 | Pass | johndoe: iPad Air, Safari Pass. johndoe: iPad Air, Firefox Pass. johndoe: iPad Air, Chrome Pass. |
Points of improvement
(See individual test cases in test report for more details)
F10 - The user needs to log out and then log in for video calls to be functional.
F10 - The friends list doesn't show up properly when trying to make a video call on android phone with Firefox.
F10 - Answering the video calls doesn't always work.
F10 - Camera feed does not always show.
F10 - When in a video call, the video call takes upp the entire screen, and makes it impossible to click on the camera or audio icons.
U5 - In landscape mode, some functionality is overlapping, making it difficult to access features.
U5 - Offline browsing not possible on android phone, no cached web pages shown.
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
The general feeling of using the system on an android phone or an iPad is that it's stable and works well.
But a lot of things need to be fixed in order for the application to work on android phones.
The biggest problems can be found in the video call functionality.
The system feels stable on: iPad Air, Safari, Chrome and Firefox
The system feels shaky on:
Galaxy S5 Neo, Samsung Internet, Firefox and Chrome
Making video calls feels shaky, independent of the system.
Manual testing
May 30th, 20:40
Description: Rerun of manual test cases for F1-F4 and F13.
Tester: Sofia Kristiansen
Version: 0.3
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 60.0
- Chrome 66.0.3359.181
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 42.17134.1.0
- Firefox 60.0
iPhone 5s, iOS 11.4.
Web browser:
- Safari 11
- Firefox 12
- Chrome 67
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F1 | T.1.1 | Pass | All devices: Pass. |
| F1 | T.1.2 | Pass | All devices: Pass. |
| F1 | T.1.3 | Pass | All devices: Pass. |
| F1 | T.1.4 | Pass | All devices: Pass. |
| F1 | T.1.5 | Pass | All devices: Pass. |
| F2 | T.2.1 | Pass | All devices: Pass. |
| F2 | T.2.2 | Pass | All devices: Pass. |
| F2 | T.2.3 | Pass | All devices: Pass. |
| F2 | T.2.4 | Pass | All devices: Pass. |
| F2 | T.2.5 | Pass | All devices: Pass. |
| F2 | T.2.6 | Pass | All devices: Pass. |
| F3 | T.3.1 | Pass | All devices: Pass. |
| F4 | T.4.1 | Pass | All devices: Pass. |
| F4 | T.4.2 | Pass | All device: Pass. |
| F4 | T.4.3 | N/A | Not implemented. Not F4 in the product backlog anymore. New - F46. |
| F4 | T.4.4 | N/A | Not implemented. Not F4 in the product backlog anymore. New - F46. |
| F4 | T.4.5 | N/A | Not implemented. Not F4 in the product backlog anymore. New - F46. |
| F13 | T.13.1 | Pass | All devices: Pass. |
| F13 | T.13.2 | Pass | All devices: Pass. |
| F13 | T.13.3 | Pass | All devices: Pass. |
Points of improvement
- Solved When trying to register with a faulty password, the error message is that the username is already registered. I checked the database, but a user with that username did not already exist. In other words the error handling doesn't work as expected, I was expecting the application to say that the password was faulty/too short. (Note: All other error messages works as expected)
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
The system is self explanatory and feels stable. All of the tested parts are good and the only thing that needs to be worked on is further explained in the Points of improvement above.
The system feels stable on:
- All of the tested devices and browsers.
Manual testing
May 31st, 08:57
Description: Rerun of manual test cases for F5-F7, F10 and F47.
Tester: Sofia Kristiansen
Version: 0.3
Description of the test environment
MacBook Pro, macOS High Sierra version 10.13.4.
Web browser:
- Firefox 60.0
- Chrome 66.0.3359.181
- Safari 11.1
Taurus PC, Windows 10.
Web browser:
- Microsoft Edge 42.17134.1.0
- Firefox 60.0.1
iPhone 5s, iOS 11.4.
Web browser:
- Safari 11
- Firefox 12
- Chrome 67
| Requirement | Test case | Status | Comments |
|---|---|---|---|
| F5 | T.5.1 | Pass | All devices: Pass. |
| F5 | T.5.2 | Pass | All devices: Pass. |
| F5 | T.5.3 | Pass | All devices: Pass. |
| F6 | T.6.1 | Pass | All devices: Pass. |
| F6 | T.6.2 | Pass | All devices: Pass. |
| F7 | T.7.1 | Pass | All devices: Pass. |
| F10 | T.10.1 | Pass/Fail | Mac firefox, chrome, safari, iPhone safari, PC firefox, PC edge: Pass. iPhone firefox, chrome: Fail, unable to make a video call. Only a blank page is shown. |
| F10 | T.10.2 | Pass/Fail | Mac firefox, chrome, safari, iPhone safari, PC firefox, PC edge: Pass. iPhone firefox, chrome: Fail, receives call but is unable to answer it. |
| F10 | T.10.3 | Pass | All devices: Pass. |
| F10 | T.10.4 | Pass/Fail | Mac firefox, chrome, safari, PC firefox, PC edge: Pass. iPhone safari: Pass/Fail, able to mute microphone, but in some cases the app freezes when trying to unmute. (See details below) iPhone firefox, chrome: Fail, unable to test. |
| F10 | T.10.5 | Pass/Fail | Mac firefox, chrome, safari, iPhone safari, PC firefox, PC edge: Pass. PC edge: Pass/Fail, in some cases unable to hide the camera feed. (See details below) iPhone firefox, chrome: Fail, unable to test. |
| F10 | T.10.6 | Pass/Fail | Mac firefox, chrome, safari, iPhone safari, PC firefox, PC edge: Pass. iPhone firefox, chrome: Fail, unable to test. |
| F47 | T.47.1 | Pass | All devices: Pass. |
| F47 | T.47.2 | Pass | All devices: Pass. |
| F47 | T.47.3 | Pass | All devices: Pass. |
| F47 | T.47.4 | Pass | All devices: Pass. |
| F47 | T.47.5 | Pass | All devices: Pass. |
Additional details from testing video calls
Test case T.10.1
Unable to make calls from iPhone firefox and iPhone chrome regardless of which device and browser who was the callee.
The table shows which device and browser that can call the specific callee.
| Caller | Callee | Comments |
|---|---|---|
| Mac firefox, Mac chrome, Mac safari, iPhone safari | PC firefox | Pass |
| Mac firefox, Mac chrome, Mac safari, iPhone safari, PC firefox | PC edge | Pass, but takes a while to connect. |
| Mac chrome, Mac safari, iPhone safari, PC firefox, PC edge | Mac firefox | Pass |
| Mac firefox, Mac safari, iPhone safari, PC firefox, PC edge | Mac chrome | Pass |
| Mac firefox, Mac chrome, iPhone safari, PC firefox, PC edge | Mac safari | Pass |
| Mac firefox, Mac chrome, Mac safari, PC firefox, PC edge | iPhone safari | Pass |
| Mac firefox, Mac chrome, Mac safari, PC firefox, PC edge | iPhone chrome | Fail. Able to make call, but iPhone chrome can not answer it. |
| Mac firefox, Mac chrome, Mac safari, PC firefox, PC edge | iPhone firefox | Fail. Able to make call, but iPhone firefox can not answer it. |
Test case T.10.2
Able to receive calls on all devices and browsers regardless of which device and browser who was the callee, but unable to answer the calls on iPhone firefox and chrome.
Test case T.10.3
No problems whatsoever.
Test case T.10.4
Unable to test on iPhone firefox and iPhone chrome, since it is not possible for these browsers to make or answer video calls.
On iPhone safari the application sometimes freezes when muting/unmuting the microphone. This happens when the caller is one of the following: Mac firefox, Mac chrome or Mac safari. Or the callee is one of the following: Mac chrome or Mac safari.
Note! The application does not freeze when the caller or callee is PC firefox or PC edge. Or when the callee is Mac firefox.
Test case T.10.5
Unable to test on iPhone firefox and iPhone chrome, since it is not possible for these browsers to make or answer video calls.
On PC edge the camera feed can't be hidden by toggling the camera icon. This happens when the caller or callee is one of the following: Mac firefox, Mac chrome, Mac safari or PC firefox.
Note! One is able to toggle the camera feed on PC edge when the callee is iPhone safari. However, not when the caller is iPhone safari.
Test case T.10.6
Unable to test on iPhone firefox and iPhone chrome, since it is not possible for these browsers to make or answer video calls.
Points of improvement
- Not solved On Mac firefox: If the first thing I do is to start a solo-chat, I am not able to go into the chat page anymore. To start a chat room I have to go to the friends page and start a chat from there. Then I am able to go into the chat page once more.
- Not solved On Mac firefox: When leaving the only chat room created the user does not get redirected to the chat page. It loads forever.
- Not solved Unable to make video calls on iPhone firefox and iPhone chrome. Only a blank page is shown.
- Not solved Unable to answer video calls on iPhone firefox and iPhone chrome.
- Not solved On iPhone safari the application sometimes freezes when muting/unmuting the microphone. This happens when the caller is one of the following: Mac firefox, Mac chrome or Mac safari. Or the callee is one of the following: Mac chrome or Mac safari. Note! The application does not freeze when the caller or callee is PC firefox or PC edge. Or when the callee is Mac firefox.
- Not solved On iPhone safari there is no camera feed when calling PC edge.
- Not solved Unable to hide the camera feed on PC edge, except for when the callee is iPhone safari.
- Not solved Unable to make video calls from PC edge to PC firefox. The call ends by itself, but this might have to do that the call is made and received on the same PC.
- Not solved When PC edge, PC firefox or Mac firefox calls or gets called by Mac safari, and Mac safari hides the camera feed, the black box is shown in portrait mode instead of landscape mode.
Analysis
((Describe the feeling of the system, does it feel stable/shaky, what parts are good, what needs to be worked on.))
All of the tested parts are good, except for F10 video calls that the group has not been able to spend a lot of time on to get bug free. This is the main thing that needs to be worked on in the future to make the system feel stable. Suggestions as to what needs to be worked on is further explained in the Points of improvement above, and further detailed in the Additional details from testing video calls.
The system feels stable on:
- Mac firefox, chrome and safari.
- PC firefox and edge.
- iPhone safari.
The system feels shaky on:
- iPhone firefox and chrome, but this only have to do with the video calls not working properly in these browsers on iPhone. All other parts of the system feels stable on iPhone firefox and chrome.
Automated testing
Server stress test, May 31st, 14:40
Test author: Andrew Galbraith
Test runner: Sofia Kristiansen
Description: Stress testing the server with 200 users. Requirement P1.
Technical documentation
In this document you'll find information about the technology used in the project.
Development environment
Operating systems: Windows, MacOS.
IDE: Visual Studio for Mac, Atom, WebStorm or any other optional IDE.
Programming language
Back-end: C# in ASP.NET Core.
Front-end: Javascript (ES6) in React.js.
Hosting and Architecture
The client, server and database used in the project are all hosted within Microsoft Azure accorrding to the following diagram.
Client
React.js client deployed to Azure.
Client technical documentation
Server
A ASP.NET Core server deployed to Azure.
Server technical documentation
Database
Azure Cosmos DB.
Database technical documentation
Code standard
JavaScript standard.
C# coding conventions.
Suggestions technology
Here you'll find the different suggestions to what technology to use to implement the customer's requirements. The suggestions are taken from an analysis made by the group on what kind of technology that is used in similar systems.
Real-time text chat: ASP.NET SignalR.
Encryption: Signal Protocol library for JavaScript.
Real-time video calls and Live streaming: WebRTC.
Authentication/Authorization: JWT.
Proof of concept
Proof of concept is a realization of a certain method or idea in order to demonstrate its feasibility. Here you'll find the proof of concept for the different technologies.
PoC real-time text chat
ASP.NET SignalR proof of concept code: PoC
ASP.NET SignalR proof of concept URL: PoC
PoC Video call
WebRTC proof of concept code: PoC
WebRTC proof of concept URL: PoC
Technical documentation server
This page contains documentation concerning technical aspects of the RedRiver server.
The RedRiver server is primarily designed as an api server, and so the client and server communicate through API calls. However, the messaging system uses SignalR.
Frameworks and Architecture
The base server implemention uses ASP.NET Core 2. This has the advantage of being compatible with the majority of operating systems, in contrast to earlier ASP.NET variants.
An MVC architecture is inherent to the ASP.NET framework and this has been followed in order to allow for separation of concerns. However, since we have an external client which is not served from ASP.NET, the V (View) in MVC has no relevance in this particular context.
Technology
- HTTP requests and responses - ASP.NET HTTP
- Websockets - SignalR
- Video call and streaming - WebRTC
- Authentication/Authorization - JWT
Hosting
At present the server is hosted as an Azure webapp. App generation and configuration can be configured through the Azure Portal, although the particular logins necessary for this project are not published here.
Deployment
All changes to the master branch of the repository are automatically pushed to the deployment server on Azure.
Installation
Installation instructions are found in the repo's README.md.
Architecture
To show the structure of the application/system we use a UML class diagram. A class diagram is a type of static structure diagram that describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects.
The arrows represents the relationship between classes:
For more information about the notation used click here: Wikipedia
Technical documentation client
Framework
React.js with React Router for routing. The client application will be built on the React-framework. When using React, handling navigation gets really simple with the help of state-handling and React Router. In React, it is also easy to create components that can be reused, which gives a consistent look and feel throughout the application and follows the DRY-principle. React also includes some great developer tools that can be installed as Chrome-extensions to facilitate the development.
Design
- UI Component Library: MaterialUI
- CSS for styling of all HTML5-elements.
<div>,<h1>,<p>etc. - JSS - CSSinJS for styling of all imported components such as Material-UI.
All elements in the client code that have aclassNameoridattribute use normal CSS, and all elements that have astyleattribute use JSS. - Material-UI Theme Provider - Is used to provide a theme. This makes it easy to change colors throughout the application by creating palettes.
Layout
Screen Breakpoints: Source
- xs, extra-small: 0px or larger
- sm, small: 600px or larger
- md, medium: 960px or larger
- lg, large: 1280px or larger
- xl, xlarge: 1920px or larger
Technology
- API-communication - Axios
- Websockets - SignalR Javascript Client
- Video call and streaming - WebRTC
- Authentication/Authorization - JWT
Hosting
At present the server is hosted as an Azure webapp.
Deployment
All changes to the master branch of the repository are automatically pushed to the deployment server on Azure.
Installation
Installation instructions are found in the repo's README.md
Architecture
To show the structure of the application/system we use a UML class diagram. A class diagram is a type of static structure diagram that describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects.
The arrows represents the relationship between classes:
For more information about the notation used click here: Wikipedia
Server API
Database
Hosting
The database for this project is hosted on Azure at: https://redriver.database.windows.net
Choice of Database and Table Creation
At present the RedRiver server uses a Microsoft SQL relational database for all data storage. This has the advantage of playing nicely together with ASP.NET and is the default choice in this context. The Identity framework, together with the Entity framework used in ASP.NET creates its own set of tables in a database, which stem from the ApplicationUser class. ApplicationUser inherits from IdentityUser and so has more fields than shown here.
public class ApplicationUser : IdentityUser
{
public ApplicationUser()
{
this.Friendships = new HashSet<Friendship>();
}
public string SocialSecurity { get; set; }
public string StreetAddress { get; set; }
public string City { get; set; }
public string Country { get; set; }
public string Postcode { get; set; }
public string FirstName { get; set; }
public string Surname { get; set; }
public string RelativeUsername { get; set; }
public string TelephoneNumber { get; set; }
public virtual ICollection<Friendship> Friendships { get; set; }
}
ApplicationUser contains an ICollection (implemented as a HashSet) which is designed to represents Friendships. The Friendship class is as follows:
public class Friendship
{
public int FriendshipId { get; set; }
public string FriendUsername { get; set; }
public string FriendId { get; set; }
[ForeignKey("ApplicationUserId")]
public string ApplicationUserId { get; set; }
public DateTime Time { get; set; } = DateTime.Now;
}Generated Tables
Entity Framework automatically creates the following tables upon system start if they do not already exist.
Below is a closer look at the AspNetUsers table, which reflects the fields implemented in the ApplicationUser class. Not all tables relating to the user table are shown for the sake of clarity. Users roles for admin and superuser are available, and the diagram shows the join table between NetUsers and NetRoles.
Improvements
This set of classes does not represent the best choice for a relational database since it leads to data duplication; a "friend" in this context is actually another user . FriendUserName is then information which is also stored elsewhere and could be determined by a lookup. However, it is convenient at present. A better choice would be an ICollection
Similarly, when two users become friends two entries are made in the Friendships table i.e. a friendship is currently one way only. There is possibly room for improvement in this system since friendships in practice are always mutual.
Security
The chosen database is secure in the sense that Azure provides the option of encrypting all information in the database. While this may seem desirable, it may not provide full security since the encryption methods are not known and the ability for Microsoft to withstand legal challenges from government agencies is unclear.
ToDo
Further database tables will be required in accordance with the functional requirements. It is possible that friendship requests will have to be stored, necesitating a table. A table for logging will also be required.
Update 20180502
Tables have been added to the database to cope with group chat and logs. A group chat is referred to as a "room" within the database.
SignalR
SignalR runs via RPC(remote procedure calls) which means that it consists of a number of simple commands on both client and server, but that it has the ability to invoke other functions on the client/server. This makes it very flexible, but requires the client and the server to have agreed upon a common set of commands.
In the client commands shown here, the string after the invoke command reflects the C# method name on the server and any alteration clientside must also be altered on the server.
Connection
Calls to the SignalR section of the server must access the /chat route and carry the users bearer token as shown in the example below:
const chatLocalUrl = "http://localhost:49873/chat";
this.state.connection = new signalr.HubConnection(chatLocalUrl+"?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0dXNlciIsImVtYWlsIjoidGVzdHVzZXJAaG90bWFpbC5jb20iLCJqdGkiOiI0NDdiM2ZmNi0xZGJmLTQ2YjktODNmZC05MjVlYjI4MGE4MTUiLCJyb2xlcyI6InVzZXIiLCJleHAiOjE1MjQ0MjkzMTEsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6NjM5MzkvIiwiYXVkIjoiaHR0cDovL2xvY2FsaG9zdDo2MzkzOS8ifQ.ep2n5ZPNR6dTRdDETalHuLpPbYu56BojUgRn_-EeccQ");Carrying the bearer token in the url is far from ideal, but at present is the only workable solution. In the future it may be possible to exchange the token as a SignalR message.
Connections are given an id and currently stored in an in-memory dictionary with username as key on the server.
Chats and Joining groups
In the finished product, every conversation should take the form of a group conversation (even if there are only two participants) and must have a name. Other methods providing user to user direct messaging and user to all direct messaging are implemented for test purposes. Groups are stored in-memory for quick access, but also backed up to database, so a user logging in after a logout should still be a participant in the same groups.
All groups must have a name. The server provides a group name to avoid security problems with accidentally matching group names and this is relayed to the client.
Method invocations for joining groups
Below are several methods used to create and add users to groups. These are under construction and are subject to change.
JoinGroup(string groupName)
To create a group, the calling function must specify a group name which does not presently exist. If the group does exist, the user will join this group.
this.state.connection.invoke("joinGroup", groupName);
This adds the user to the group on the server, commits the changes to database and then responds by calling invoking a client method according to the following code:
Clients.Group(groupName).InvokeAsync("userAddedToGroup", new[] { name, groupName });The clientside code to handle this is defined as follows:
this.state.connection.on('userAddedToGroup', (name, group) => {
//Code here
});AddClientToGroup(string groupName, string usernameToAdd)
Designed to add a single user to existing group.
StartGroupChatWithMultipleClients(string[] usernames)
Designed to create a group chat from scratch with multiple users.
LeaveGroup(string groupName)
Removes the calling user from a group.
Sending Messages
A message is sent as shown below.
this.state.connection.invoke("sendMessageToGroup", groupName, message);
The server will then send the message to the group by invoking a client method.
Clients.Group(groupName).InvokeAsync("messageSentToGroup", new[] { groupName, name, message });which in turn is defined on the client as:
this.state.connection.on('messageSentToGroup', (group,senderName,message) => {
//Code here
});Sending Messages - Convenience Methods
For testing convenience the following methods can also be called on the server:
SendMessageToUser
this.state.connection.invoke("sendMessageToUser", username, message);
calls client according to:
Clients.Client(connectionId).InvokeAsync("messageSentToSpecificUser", new[] { senderName, message });SendMessageToAllConnectUsers
this.state.connection.invoke("sendMessageToAllConnectedUsers", this.state.message);calls client according to:
Clients.All.InvokeAsync("messageSentToAllConnectedUsers", new[] { senderName, message });Receiving Messages
The following format for client methods called by server is currently defined by serverside code.
//Various info messages groupwise
this.state.connection.on('addInfoMessageFromGroup', (group, message) => {
//Code here
});
//Called when a user connects or disconnects, and so can be used to
//update a users online status.
this.state.connection.on('alterFriendStatus', (name, group, status) => {
//Code here
});
//Useful for initial testing
this.state.connection.on('messageSentToSpecificUser', (name, message) => {
//Code here
});
//Useful for initial testing
this.state.connection.on('messageSentToAllConnectedUsers', (name, message) => {
//Code here
});
this.state.connection.on('messageSentToGroup', (group,senderName,message) => {
//Code here
});
this.state.connection.on('userAddedToGroup', (name, group) => {
//Code here
});
this.state.connection.on('userLeftGroup', (name, group) => {
//Code here
});
WebRTC
WebRTC explained
WebRTC is a collection of standards and protocols that enable clients to establish a P2P connection that can be used to stream video and audio or send data without relying on plugins or other third-party software. The functionality is available through a high-level browser API.
Three different interfaces are being used when working with WebRTC:
- RTCDataChannel - Channel to transfer data. Sample
- MediaStream - Channel to transfer audio and video. Sample
- RTCPeerConnection - Used for linking of two peers. Both clients need to instantiate a
RTCPeerConnectionbefore being able to create aDataStreamorMediaStream. Sample
WebRTC use these concepts and technologies to establish a connection:
Session Description Protocol (SDP) - Peers need to agree on a contract before establishing a connection. SDP is used to describe the details of this contract. ”Peer 1” sends a SDP offer to ”Peer 2” who generates an SDP answer that is returned to ”Peer 1”. ”Peer 2” either accept or rejects the SDP offer sent from ”Peer 1”.
Interactive Connectivity Establishment (ICE) - To be able to reach each other, the two peers needs to exchange addresses and ports. Usually a peer is located behind a NAT, firewall or other barriers, which means that it doesn't expose a direct public IP address. The process of ICE makes it possible to traverse the NAT. The protocols used for this are STUN and TURN.
SignalR - SignalR on the server acts a middleman to help peers initiate a connection by exchanging SDP offer and SDP answer. Once a connection is established, the peers communicate P2P without any involvement of server. This reduce load on the server.
PoC
WebRTC proof of concept code: PoC
WebRTC proof of concept URL: PoC
Video call
1. Peer 1 instantiates a RTCPeerConnection - A url to Googles STUN-server is added. This server is being used to get the identity of the peers.
const PC_CONFIG = { iceServers: [{ urls: ['stun:stun.l.google.com:19302'] }] };
this.pc = new RTCPeerConnection(PC_CONFIG);2. Peer 1 creates a MediaStream - The API method addStream() is used to send a local video/audio stream from the computer.
pc.addStream(localStream);
3. Peer 1 creates a SDP offer - The API method createOffer() is used to create a SDP offer for Peer 2. After the off has been created, a local description for the peer is set by the API method setLocalDescription(). This description include whether it is a video/audio or data transfer, size of video, types of data and other useful information about the requested connection.
createOffer() {
this.pc.createOffer()
.then(this.pc.setLocalDescription(desc);)
.catch(err => console.log(err));
return this;
}4. Peer 1 gathers ICE candidates - RTCIceCandidate() gather information about peers identities and what server to use when establishing a RTCPeerConnection.
addIceCandidate(candidate) {
if (candidate) {
const iceCandidate = new RTCIceCandidate(candidate);
this.pc.addIceCandidate(iceCandidate);
}
return this;
}5. Peer 1 sends offer to Peer 2 - To send the initial offer to the other peer, SignalR is used both on client and server. Client use HubConnection to invoke the method Call on server who then send the SDP offer to Peer 2.
import { HubConnection } from '@aspnet/signalr';
let userConnection = new HubConnection(serverUrl);
userConnection.invoke('Call', { to: this.friendID, sdp: desc });
6. Peer 2 instantiates a RTCPeerConnection - When Peer 2 receives a offer from Peer 1, a RTCSessionDescription() is created with information about both peers.
userConnection.on('call', (data) => {
if (data.data.sdp) {
const rtcSdp = new RTCSessionDescription(data.data.sdp);
this.pc.setRemoteDescription(rtcSdp);
if (data.data.sdp.type === 'offer') this.pc.createAnswer();
} else this.pc.addIceCandidate(data.data.candidate);
});7. Peer 2 generates a SDP answer based on Peer 1's offer - createAnswer() creates an answer for Peer 1 and description for Peer 2 is set with setLocalDescription().
createAnswer() {
this.pc.createAnswer()
.then(this.pc.setLocalDescription(desc))
.catch(err => console.log(err));
return this;
}8. Peer 2 gathers ICE candidates - The method RTCIceCandidate() is also used to get information about Peer 2.
9. Peer 2 sends answer to Peer1 - SignalR is used to send back an answer to Peer 2.
this.connection.invoke('Call', { to: this.friendID, sdp: desc });Diagram
Live streaming
Same process as video calls but instead of creating a connection between peers, it is established between one peer and the server. Once a MediaStream is established, other peers can make a request access to it from server.
Diagram
SendGrid
About
SendGrid is used to send out verification emails to newly registered users. It is a cloud-based email service that provides reliable transactional email delivery, scalability, real-time analytics and a flexible API that make custom integration easy.
Pricing
SendGrid offers different plans depending on how many emails you want to send out per month. As of now, the application is using the free plan, which after the first 30 days only lets you send out 100 emails/day. All free of charge. More information on SendGrids pricing can be found here.
Source code
As of now, all newly registered users must verify their email before being able to log into the application. This setting can be toggled in the file server/RedRiverChatServer/StartUp.cs row 59-60:opt.SignIn.RequireConfirmedEmail = true;
Settings for the email is set in the file server/RedRiverChatServer/appsettings.json and later used in the Register method in AccountController.cs and EmailSender.cs. These settings needs to be configured to fit your information.
Handover
SendGrid
At handover the created SendGrid account will be transfered to you to avoid you having to spend time on getting the settings right. As of now, the account is set out to Sofia Kristiansens school email, but this will be changed to an email address of your choice. The username and password will be sent to you in an email and after logging in for the first time you should:
- Go to account settings.
- Edit the password.
- Add other information of your choice.
When you're done with the above do the following to create a new API key to be used by the application:
- In the menu to the left, click on Settings.
- In the dropdown, click on API Keys.
- Click on the button where it says "Create API Key".
- Name the key whatever you want.
- Choose API Key Permissions "Full Access".
- Click the button "Create & View".
- Make a note of the API Key and save it. This is the only time you'll ever see it.
Source code
Email settings needs to be configured to fit the information you want the user to get in the verification email. These settings are found in the file server/RedRiverChatSettings/appsettings.json.
- Open the appsettings.json file.
- Scroll down to "Client".
- Change the following information:
- WebAddress - Change to the address of your client.
- EmailAddress - The email you want the newly registered users to see as the sender of the email.
- Subject - The subject of the email. Currently set to "Bekräfta din mailadress".
- Message - The message of the email. Here you can add a link to your terms of service.
- SendGridApiKey - Either paste your created SendGrid API Key from before (not recommended!) or delete this row and follow the guides below.
The SendGrid API Key should be stored in a secure way. This can be done by following:
Easy to follow guide.
Or this (depending on your prior experience):
This guide.
UI and design
We have used Material-UI which contains a lot of predefined design elements. Material-UI are React components that implement Google's Material Design.
When RedRiver looked at an early version of our application, they liked that the UI was simple and easy to understand. So we have kept to this design wise, with some smaller changes.
Typeface
We changed the typeface from Material-UI:s default Roboto, to the rounder sans-serif typeface "Nunito" from Google Fonts.
The reason for this choice was that it went well with RedRiver's logo, which is shaped from two round rings.
It also gives a friendly, warm feeling which felt appropriate considering the target group for the application.
We only included the regular and semi-bold variants of the typeface, to bring down loading time of the application.
Colors
The color scheme has been changed slightly, from grey to a dark blue/neutral color scheme. This went well with the original target group, where the chat application would be used for communication between doctors and patients in the medical field. It also works well for a larger audience, since blue gives a more serious and neutral impression.
WCAG 2.1
Special consideration has been taken to make the design comply with WCAG 2.1. We have made sure there is adequate contrast according to WCAG recommendation 1.4.3: "so that people who have a color vision deficit will also have adequate contrast between the text and the background".
Glossary
Below is an alphabetical wordlist with definitions as they apply to the RedRiver project.
Admin - An application user with certain raised privileges e.g. the ability to delete accounts of normal users.
API - Application Programming Interface - this is a set of clearly defined methods of communication between software components. In the case of this project, the api is used for communication between the client and the server.
User - A standard application user with no raised privileges.
Superuser - An application user with the ability to raise and lower the privileges of an admin user.
Iteration 0
Time report iteration 0
| Name | Sum iteration | Time total in project |
|---|---|---|
| Andrew | 6.5 | 6.5 |
| Jimmy | 9 | 9 |
| Linda | 0 | 0 |
| Sofia | 9.5 | 9.5 |
Detailed time report iteration 0
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Lecture | Watch introduction | Done | 5.25 | 3 | Group |
| Group meeting | Distribute tasks, decide on roles | Done | 3 | 1.5 | Group |
| Github repo | Setup Github repo for the project | Done | 1.5 | 1 | Jimmy |
| Tutor meeting | Send three potential times for the weekly meetings | Done | 1 | 1 | Andrew |
| Post mortem | Read at least one post mortem from previous years, write down comments | Started | 6 | 4 | Group |
| Customer meeting | Initial contact with customer | Done | 1 | 1 | Andrew |
| Github wiki | Create all wiki pages for the documentation | Done | 2 | 2 | Sofia |
| Project plan | Start writing | Started | 1 | 1.5 | Sofia |
| Vision | Start writing | Started | 0.5 | 0.5 | Sofia |
| Risk list | List and prioritize as many risks as possible | Started | 2 | 2.5 | Group |
| Documentation | Diagrams | Started | 2 | 2 | Jimmy |
| Requirements | Begin defining requirements | Started | 2 | 0.5 | Andrew |
| Time report | Write for the first week | Started | 3 | 2.5 | Group |
| Iteration plan | Create for iteration 1 | Started | 3 | 1.5 | Group |
| Sum | 33.25 | 25 | |||
| Time since previous iteration | 0 | ||||
| Time total in the project | 25 |
New risks
Any new risks should be written here.
Goals for iteration 1
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during start-up week | Not started | 4 | - | Group |
| Group meeting | Discuss iteration plan | Not started | 2 | - | Group |
| Time report | Create for iteration 1 | Not Started | 4 | - | Group |
| Iteration plan | Create for iteration 2 | Not started | 4 | - | Group |
| Vision | Start writing | Not started | 4 | - | Andrew |
| Product backlog | Start writing requirements | Not started | 3 | - | Andrew |
| Project plan | Update | Not started | 5 | - | Sofia |
| Customer meeting | Meeting concerning tech implementation | Not started | 4 | - | Group |
| Risk list | Update | Not started | 3 | - | Jimmy |
| Glossary | If needed, write down glossary for the project | Not started | 1 | - | Andrew |
| Test specification | Start writing tests for the high priority requirements | Not started | 7 | - | Sofia |
| Implementation | Focus on investigating the projects size, tech, feasibility | Not started | 10 | - | Jimmy |
| Sum | |||||
| Time since previous iteration | 25 | ||||
| Time total in the project |
Iteration 1
Analysis of the previous iteration
We got started with all the tasks we set out to get started with. We were two persons short due to sickness and one did not have the intention to participate in the course. We distributed the roles; the project manager role is going to alternate every two weeks, Sofia is test manager, Jimmy is technical manager, Andrew and Linda are requirement managers and are responsible for customer contact.
Andrew had his initial contact with the customer. Jimmy set up our Github repo, wrote a risk list and started with the architecture diagrams for the system. Sofia set up the wiki pages, started writing on the project plan and vision. Other tasks that were done can be found in the time report in iteration 0 and in the individual time reports.
It has been a slow but steady start and we are eager to get started with the project.
Time report iteration 1
| Name | Sum iteration | Time total in project |
|---|---|---|
| Andrew | 15.5 | 21.5 |
| Jimmy | 15.75 | 24.75 |
| Linda | 20.75 | 20.75 |
| Sofia | 14.25 | 23.75 |
Detailed time report iteration 1
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during start-up week | Done | 4 | 2 | Group |
| Group meeting | Discuss iteration plan | Done | 2 | 4 | Group |
| Time report | Create for iteration 1 | Done | 4 | 3.75 | Group |
| Iteration plan | Create for iteration 2 | Started | 4 | 0.25 | Group |
| Customer meeting | Meeting concerning tech implementation | Done | 4 | 3 | Group |
| Vision | Start writing | Done | 4 | 2 | Andrew |
| Vision | Update | Done | 0.5 | 0.5 | Linda |
| Vision | Read updated vision | Done | 0.25 | 0.25 | Sofia |
| Product backlog | Start writing requirements | Done | 4 | 4 | Andrew |
| Product backlog | Prioritize requirements and add comments | Done | 5.5 | 6.25 | Group |
| Product backlog | Update requirements and add missing ones | Done | 1 | 1.5 | Linda |
| Product backlog | See if requirements are testable | Started | 2 | 0.25 | Sofia |
| Project plan | Update | Done | 3 | 2 | Sofia |
| Project managing | Write list to make it clear what needs to be done before next group meeting | Done | 1 | 1 | Sofia |
| Group discussion | Discuss on Slack | Done | 2.75 | 2.25 | Group |
| Github wiki | Get info about Waffle.io | Done | 2 | 0.5 | Jimmy |
| Github wiki | Rename wikipages | Done | 0.25 | 0.25 | Sofia |
| Github wiki | Update home with correct links | Done | 0.25 | 0.25 | Jimmy |
| Risk list | Update | Done | 3 | 1.5 | Jimmy |
| Version control | Investigate and set up version control | Done | 1.5 | 2.5 | Jimmy |
| Version control | Investigate version control | Done | 1 | 1 | Andrew |
| Version control | Try out the version control work flow | Done | 0.75 | 0.75 | Sofia |
| BankID | Look up and write email to customer | Done | 2 | 2 | Sofia |
| SignalR POC | Initial check for suitability | Done | 4 | 4 | Andrew |
| Glossary | If needed, write down glossary for the project | Not started | 1 | - | Andrew |
| Test specification | Start writing tests for the high priority requirements | Not started | 4 | 0 | Sofia |
| Implementation | Investigate the projects tech | Done | 3 | 3.25 | Group |
| Implementation | Initialize client | Done | 4 | 3.5 | Jimmy |
| WebRTC POC | Start creating POC for video chat | Started | 1 | 1 | Jimmy |
| Documentation | Research update order of pages, catch up on documentation, discuss with group, update | Done | 2 | 2 | Linda |
| Lecture | Watch course introduction | Done | 1.75 | 1.5 | Linda |
| Project knowledge | Read through entire course page, requirements from RedRiver, repo | Done | 2.5 | 2.5 | Linda |
| Customer communication | Send e-mail to client RedRiver/Mattias regarding Mobile BankID | Done | 0.5 | 0.5 | Linda |
| Question document | Add document to repository with questions to client RedRiver, regarding requirements | Done | 1 | 2 | Linda |
| Question document | Add new questions | Done | 2 | 2.75 | Linda/Sofia |
| Post mortem | Read one post mortem from previous years | Done | 2 | 1.5 | Linda |
| Sum | 81.5 | 66.25 | |||
| Time since previous iteration | 25 | ||||
| Time total in the project | 91.25 |
New risks
Any new risks should be written here.
Goals for iteration 2
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during iteration 1 | Not started | 4 | - | Group |
| Group meeting | Discuss work done, the new iteration plan and distribute tasks | Not started | 4 | - | Group |
| Time report | Create for iteration 2 | Not Started | 4 | - | Group |
| Iteration plan | Create for iteration 3 | Not started | 4 | - | Group |
| Vision | Send to customer for signing | Not started | 1 | - | Andrew |
| Client questions | Send question document to customer | Not started | 1 | - | Andrew |
| Product backlog | See if requirements are testable | Not started | 1.75 | - | Sofia |
| Test specification | Start writing tests for the high priority requirements | Not started | 8 | - | Sofia/Linda |
| Implementation | Focus on investigating the projects size, tech, feasibility | Not started | 10 | - | Group |
| POC | Create proof of concept for the available technology | Not started | 10 | - | Jimmy/Group |
| Software architecture | Preliminary architecture for the project | Not started | 8 | - | Andrew/Jimmy |
| Wireframe | Set up environment for mock/prototype | Not started | 3 | - | Linda |
| Inception | Gather and send inception material to Group 0 | Not started | 4 | - | Sofia |
| Sum | 62.75 | ||||
| Time since previous iteration | 91.25 | ||||
| Time total in the project |
Iteration 2
Analysis of the previous iteration
This was the first week on the project for our fourth member and she has had to acquaint herself with the work that was done during the start-up week.
The whole group has gone through the product backlog, that was written by Andrew, and prioritized the requirements. We have all commented on what needs to be clarified by the customer for us to write better requirements that are testable. These comments have been made into questions that we all wrote down in a document to send to the customer during the coming week.
The vision was updated and is ready to be sent to the customer. The project plan has been updated with important milestones for the project and the course.
Jimmy has set up a version control system for us to use when working on the same Github repo and we have all acquainted ourselves with it by testing it.
We have started to find technical solutions to the different parts of the chat application and written them down in the wiki Technical documentation.
Time report iteration 2
| Name | Sum iteration | Time total in project |
|---|---|---|
| Andrew | 20 | 41.5 |
| Jimmy | 20.75 | 45.5 |
| Linda | 13.5 | 34.25 |
| Sofia | 27 | 50.75 |
Detailed time report iteration 2
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during iteration 1 | Done | 4 | 2 | Group |
| Group meeting | Discuss work done, the new iteration plan and distribute tasks | Done | 4 | 4 | Group |
| Time report | Create for iteration 2 | Done | 4 | 5.25 | Group |
| Iteration plan | Create for iteration 3 | Done | 4 | 1.5 | Group |
| Vision | Send to customer for signing | Done | 1 | 0.5 | Andrew |
| Client questions | Send question document to customer | Done | 1 | 0.5 | Andrew |
| Product backlog | See if requirements are testable | Done | 1.75 | 4 | Sofia |
| Test specification | Start writing tests for the high priority requirements | Done | 8 | 6.5 | Sofia/Linda |
| Implementation | Focus on investigating the projects size, tech, feasibility | Done | 10 | 10.75 | Group |
| POC | Create proof of concept for the available technology | Done | 10 | 27 | Jimmy/Group |
| Software architecture | Preliminary architecture for the project | Not started | 8 | 0 | Andrew/Jimmy |
| Wireframe | Set up environment for mock/prototype | Done | 3 | 2.25 | Linda |
| Inception | Gather and send inception material to Group 0 | Done | 4 | 3 | Sofia |
| Group work | Extra work done by group members, see individual time reports | Done | 0 | 14 | Group |
| Sum | 62.75 | 81.25 | |||
| Time since previous iteration | 91.25 | ||||
| Time total in the project | 172.5 |
New risks
Any new risks should be written here.
Goals for iteration 3
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during the week | Not started | 4 | - | Group |
| Group meeting | Discuss iteration plan | Not started | 2 | - | Group |
| Time report | Create for iteration 3 | Not Started | 4 | - | Group |
| Iteration plan | Create for iteration 4 | Not started | 4 | - | Group |
| Sum | |||||
| Time since previous iteration | |||||
| Time total in the project |
Iteration 3
Analysis of the previous iteration
In the start of the week we sent our vision and question document to the customer. Later the same week the vision was signed off and some of our questions regarding the requirements were answered.
Andrew has been developing proof of concept for Signal encryption, but abandoned it due to browser limitations and encryption being a tricky subject. In the coming week we will look into other alternatives for the encryption and Sofia will give Signal one last try before abandoning it for other technology.
Andrew went on with the proof of concepts and started developing a server auth api and automated tests for the api using Postman.
Jimmy started and finished a proof of concept for video calls using WebRTC. This can be found here.
Linda has been working on setting up a clickable prototype in Draw.io for everyone in the group to be able to work on the same prototype simultaneously. She has also been writing the first test cases for the highest prioritized requirements, updated the documentation for the inception peer-review and prepared for the upcoming role as project manager.
Sofia has been looking into if the requirements are testable or not and come up with example test cases. She has also sorted the requirements in our google product backlog and transfered them to the wiki product backlog. In collaboration with Linda she also updated the documentation for the inception peer-review.
The group has been able to do everything that was supposed to be done during the inception phase.
Time report iteration 3
| Name | Sum iteration | Time total in project |
|---|---|---|
| Andrew | 22.5 | 64 |
| Jimmy | 23.5 | 69 |
| Linda | 33.25 | 67.5 |
| Sofia | 23.25 | 74 |
Detailed time report iteration 3
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during iteration 2 | Done | 4 | 3.25 | Group |
| Group meeting | Discuss work done, the new iteration plan and distribute tasks | Done | 4 | 3 | Group |
| Customer meeting | Discuss project | Done | 4 | 1.75 | Group |
| Slack communication | Discuss project | Done | 8 | 5.25 | Group |
| Time report | Create summarized time report for iteration 2 | Done | 3 | 3 | Linda |
| Iteration plan | Create time report (iteration plan) for entire group, iteration 3 | Done | 3 | 2 | Linda |
| Time report | Write individual time report (iteration plan) for iteration 3 | Done | 2 | 4 | Group |
| Time report | Write individual time report (iteration plan) for iteration 4 | Done | 2 | 0.5 | Group |
| Peer Review (Referentgranskning) | Write individual peer reviews in google document | Done | 4 | 11.5 | Group |
| Peer Review (Referentgranskning) | Summarize individual peer reviews to one protocol | Done | 4 | 4.5 | Linda |
| Peer Review (Referentgranskning) | Send peer review to group Meridium | Done | 0.5 | 0.25 | Linda |
| F1 User text message | Server text message functionality | Started | 7 | 3 | Andrew |
| F2 User login | Write code for server api login | Done | 1 | 1 | Andrew |
| API Tests | Write postman tests and docs for api | Started | 5 | 2 | Andrew |
| Azure install | Setup Azure and continuous delivery from repo. | Started | 2 | 1 | Andrew |
| Software architecture | Preliminary architecture for the project | Done | 5 | 5.25 | Jimmy |
| F1 User text message | Start implement text message functionality for client | Not started | 5 | 0 | Jimmy |
| F2 User login | Start implement login functionality for client | Done | 3 | 3.75 | Jimmy |
| Documentation | Put together time reports for group, update page "Iteration 2" with time report for iteration 2 | Done | 2 | 3 | Linda |
| Peer review | Add google docs document for peer review, send link to RedRiver group | Done | 2 | 0.5 | Linda |
| Group communication | Prepare for group meeting | Done | 0.5 | 0.5 | Linda |
| Project knowledge | Research Material-UI | Done | 0.25 | 0.25 | Linda |
| Group communication | Write protocol for group meeting | Done | 0.5 | 1.5 | Linda |
| Documentation | Update time report, plan for iteration 3 | Done | 1 | 0.5 | Linda |
| Documentation | Update test specification, add manual test cases. | Not started | 4 | 0 | Linda |
| Time report | Write analysis for iteration 2 | Done | 0.5 | 0.5 | Sofia |
| Signal POC | Create proof of concept for Signal Encryption | Abandoned | 4 | 0.75 | Sofia |
| Product backlog | Sort requirements based on the application being like Google Hangouts | Done | 3 | 2 | Sofia |
| Requirements F1, F2, F3, F4 | Prototype: Design/visualize the requirements | Done | 6 | 6.5 | Sofia |
| Testing | Check out test frameworks to use for auto tests on React and ASP.NET | Started | 1.25 | 0 | Sofia |
| Requirements F1, F2, F3, F4 | Test specification: Write tests for the high priority requirements | Done | 4 | 2.5 | Sofia |
| Inception presentation | Start creating the presentation | Done | 3 | 2.5 | Sofia |
| Group work | Other work done by group members, see individual time reports | Done | 0 | 26.5 | Group |
| Sum | 98.5 | 102.5 |
New risks
A big project risk at the start of this iteration was the large amount of requirements in our product backlog.
Goals for iteration 4
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during the week | Not started | 4 | - | Group |
| Group meeting | Discuss iteration plan | Not started | 2 | - | Group |
| Time report | Create for iteration 4 | Not Started | 4 | - | Group |
| Iteration plan | Create for iteration 5 | Not started | 4 | - | Group |
| Sum | |||||
| Time since previous iteration | |||||
| Time total in the project |
Iteration 4
Analysis of the previous iteration
During this week, Linda worked as project manager.
Jimmy updated the technical documentation for the server and client. He also added preliminary software architecture diagrams to the documentation. Jimmy also worked on the POC for the video chat (https://redrivervideocallpoc.azurewebsites.net/) and got video conversations working. Sofia tested the video chat POC on different browsers and operating systems.
Sofia continued researching Signal Protocol Library for JavaScript and discussed with Andrew on Slack about his previous code.
As a group we discussed the requirements in Slack, and the risks involved in working on such a large amount of requirements.
Jimmy suggested we use Material-UI, the group agreed.
Sofia worked on setting up the prototypes in Draw.io. She added templates for iPhone, iPad and Android to allow the client to see the system in different resolutions and devices.
We had a meeting with our tutor Tobias who advised us to scale down the requirements in consultation with the client, and to find the minimum viable product. Tobias also singled out the requirements that would bring up the most problems, such as quality requirements and protection against viruses. He advised us to work less on the big picture and start working on the individual requirements.
We had a client meeting with RedRiver on Tuesday, where we discussed how to solve getting an Azure subscription for the group to work in. RedRiver agreed to set up an Azure account for us and to send the link to Andrew. Linda brought up that the requirements needed to be scaled down and asked what functions were most important to RedRiver. RedRiver said that it was ok to down prioritize the encryption, and the most important aspects were text and video chat. The inspiration should be Google Hangouts. We should also down prioritize database backups.
Sofia worked on the product backlog and rearranged the requirements, finding the most basic functional ones and listing them in a good order of implementation.
Linda set up a google document for the peer review and sent the link to the group. The group members then added their own individual reflections regarding group Meridium's Inception material. When all reflections had been added, Linda compiled the individual reflections to a peer review protocol. Sofia edited the protocol and we discussed the finished protocol on Slack. Linda then sent the protocol to group Meridium.
The group discussed what the most important requirements were. Sofia wrote test cases for req. F1, F2, F3 and F4.
Jimmy invited RedRiver to our repository and Wiki. Andrew went through the requirements. Linda updated the dependencies in product backlog.
As a group we discussed adding notes on the Project page of the repository, to keep track of work that needed to be done in the project.
Andrew wrote documentation on the RedRiver Server API that he designed, wrote tests for it, and kept working on the API and database to fulfill req. F1 to F4. He also compiled the customer deliverable for the week, adding the links to our POC:s, the repository and product backlog. Along with this he wrote a document to explain and describe the delivery.
Linda worked on the prototypes in Draw.io, updating them and adding new wireframes for requirement F2. She then exported the prototypes as a clickable HTML document, which Andrew added to the deliverable. He then sent the deliverable to RedRiver.
RedRiver emailed Andrew on Friday, saying that they thought the deliverable looked great and that we were on the right track. They asked us to investigate setting up an Azure account ourselves, or a virtual machine. Andrew set up the client, server and database on his own Azure account, with the intent to run continuous delivery from our GitHub repository. Jimmy added deployment to Azure, so that everything that is added to the master branch also gets added to Azure. This way we always have a live version with the latest updates for us to see, and to show the customer.
Jimmy kept working on the client code for F1 and F2. He started implementing register and log in functionality for the client, and set up Material-UI.
During the weekend, Sofia worked on the presentation of the inception phase, setting up Google slides and timing the presentation.
Sofia received the peer review from group Futurum on our Inception material and the entire group read it during the weekend.
To summarize, we got a lot of work done during this iteration. We removed the biggest risk in the project, which was having an oversized amount of requirements.
Time report iteration 4
| Name | Sum iteration | Time total in project |
|---|---|---|
| Andrew | 21 | 85 |
| Jimmy | 26 | 95 |
| Linda | 22.5 | 90 |
| Sofia | 26.75 | 100.75 |
Detailed time report iteration 4
| Requirement | Task | Status | Estimate | Actual | Responsible |
|---|---|---|---|---|---|
| Tutor meeting | Present the work done during iteration 3 | Done | 4 | 2.5 | Group |
| Group meeting | Discuss work done, the new iteration plan and distribute tasks | Done | 4 | 2.75 | Group |
| Customer meeting | Discuss project | Done | 4 | 1.5 | Group |
| Slack communication | Discuss project | Done | 6 | 7.5 | Group |
| Time report | Create summarized time report for iteration 3 | Done | 3 | 3 | Linda |
| Time report | Write time report for iteration 4 | Done | 3 | 3.25 | Group |
| Peer Review | Peer Review Presentation (hold presentation/attend) | Done | 4 | 3.5 | Group |
| F1-F4 | Fix bugs and update login flows | Done | 6 | 8 | Andrew |
| F1-F4 API Tests | Write postman tests and docs for api | Done | 5 | 5 | Andrew |
| F5 | Research into F5, SignalR wiki docs | Done | 3 | 3 | Andrew |
| Azure fixes | Adjust delivery flow to cope with database changes | Done | 0 | 1 | Andrew |
| Time report | Write for iteration 5 | Done | 1 | 0.5 | Andrew |
| Technical documentation | Update | Done | 1.5 | 1.5 | Jimmy |
| Risk list | Update with technical risks | Done | 1 | 0.75 | Jimmy |
| Azure setup | Setup Azure automatic deployment from repo. | Done | 2 | 2 | Jimmy |
| Azure setup | Trying to fix issues with database on Azure. | Done | 1 | 2 | Jimmy |
| F1 User Register | Add API-requests. | Done | 2 | 4.25 | Jimmy |
| F2 User login | Add API-requests. | Done | 2 | 2 | Jimmy |
| F3 User own data access | Client: User can get information about themselves | Done | 3 | 5 | Jimmy |
| F4 Add friends | Client: User can add friends | Done | 6 | 3.75 | Jimmy |
| Client communication | E-mail questions to RedRiver | Done | 0.5 | 0.5 | Linda |
| Documentation | Update time report for iteration 3 | Done | 1 | 1.5 | Linda |
| Client communication | Send e-mail answer from RedRiver to group | Done | 0.25 | 0.25 | Linda |
| Client communication | E-mail new time for meeting to RedRiver | Done | 0.25 | 0.25 | Linda |
| Documentation | Write analysis of iteration 3, add to page for iteration 4 | Done | 1 | 2 | Linda |
| Documentation | Write iteration plan for iteration 4 (for group) | Done | 0.5 | 0.25 | Linda |
| Client communication | Write list of things to discuss with RedRiver | Done | 0.25 | 0.25 | Linda |
| Documentation | Add text for milestones M5 and M6, add text for deliverables | Done | 0.75 | 0.75 | Linda |
| F1 F2 F3 | Test system before meeting with RedRiver | Done | 0.25 | 0.25 | Linda |
| Peer review | Go through bullet list of needed changes from group Futurum, see if everything is updated | Done | 1.25 | 1.25 | Linda |
| Client communication | Start video call in Google Hangouts | Done | 0.25 | 0.25 | Linda |
| Peer review | Prepare Wiki for being sent to course management, add information | Done | 1 | 2.75 | Linda |
| Peer review | Clone Wiki and send to course management | Done | 0.25 | 0.25 | Linda |
| Project knowledge | Refresh knowledge on React and JavaScript | Done | 1 | 2 | Linda |
| Project plan | Update according to Group 0 peer review | Done | 1 | 1 | Sofia |
| Test specification | Update according to Group 0 peer review | Done | 1 | 1 | Sofia |
| Product backlog | Update according to Group 0 peer review | Done | 1 | 1 | Sofia |
| Vision | Update according to Group 0 peer review | Done | 2 | 2 | Sofia |
| F2 | Prototype: Update F2 user page after login | Done | 1 | 1 | Sofia |
| Vision | Update according to new customer information | Done | 1 | 1 | Sofia |
| Project plan | Update according to new customer information | Done | 0.5 | 0.5 | Sofia |
| Testing | Check out test frameworks to use for auto tests on React | Done | 1.25 | 1.25 | Sofia |
| Testing | Set up Jest test environment for front-end | Done | 3 | 3.5 | Sofia |
| F1, F2, F3, F4 | Create Jest tests for front-end | Done | 12 | 7 | Sofia |
| Testing | Update repo with screenshot from automated jest tests and clickable html-file | Done | 0.25 | 0.25 | Sofia |
| Test report | Update with screenshot and instructions on the automated jest tests | Done | 0.5 | 0.5 | Sofia |
| Test specification | Update the automated test section | Done | 0.5 | 0.5 | Sofia |
| Inception presentation | Finish the slide presentation | Done | 0.5 | 0.5 | Sofia |
| Sum | 95.5 | 96.25 |
Iteration 5
Analysis of the previous iteration
During this week, Linda worked as project manager.
All groups presented the Inception phase of their projects, and Sofia held the presentation of our project. She also presented our peer review of group Futurum's Inception material.
We had a customer meeting with RedRiver, and showed how the application looked so far.
We worked on the documentation before the final hand in of the Inception phase to the course management.
Our testing has really come under way, with Jest tests for the front end and test reports.
Requirements F1-F4 in the product backlog have gone from "Started" to "Implemented".
Time report iteration 5
View time report for iteration 5.
Iteration 6
Analysis of the previous iteration
During this week, Andrew worked as project manager.
A large part of our time this week was spent preparing for an elaboration presentation. This was primarily intended as a technical presentation and although Linda took responsibility for delivering the final presentation, each group member contributed with information and diagrams concerning the technical areas they had worked on so far - Sofia was most up to date on testing, Jimmy on the client and Andrew on the server and database.
Our collective goal during the iteration in terms of functionality was F5/F6 in our requirements i.e. implementation of chat functionality. So far we have implemented those sections of the project that are required to get chat up and running i.e. a user/login/registration system. This implementation is solid and works well. During the week, problems arose concerning SignalR and its use in the project. This problem was caused by differing versions of SignalR on the client and server, and this niggling problem cost us a lot of time. Nonetheless, the problem has been solved and Jimmy lay the groundwork for chat implementation on the client. The server code to get chat up and run exists already, although it will require further testing and refactoring for use with the client.
Sofia took time to browse the client and server code and wrote code to allow the upload of a user avater to the server, which in turn is used on the client. Sofia also reran a number of tests in order to access the impact of a number of bugfixes in the client.
In the coming iteration we hope to implement full chat functionality and improve upon the appearance of the client, while also accessing the client from a WCAG 2.0 viewpoint.
Time report iteration 6
View time report for iteration 6.
Iteration 7
Analysis of the previous iteration
During this week, Andrew worked as project manager.
The focus of this iteration was a customer delivery. We were now approaching the last week of the construction phase and as such we felt it important to communicate to the customer how far we had come in terms of implemented requirements; it was also important to reach an agreement about the state of our "final" product (in that we have only had time to implement a fraction of the total requirements) and the nature of the product final delivery.
The goal of the demonstration was to show working chat functionality and so a lot of time was spent making sure the product was in good shape ahead of the delivery demonstration. Jimmy and Andrew worked on the client and server-side respectively to eliminate various issues that had cropped up during the past weeks. Sofia continued her testing duties but also wrote server-side code to allow avatars to be uploaded. Andrew and Linda began to look at the WCAG 2.1 guidelines in order to understand what needs to be done in order to conform fully.
Linda also created mock-ups of the client with the aim of improving its appearance, both from an aesthetic and accessibility viewpoint.
The delivery went well, and we felt that we communicated clearly to the customer our thoughts around the status of the project and its future development.
Time report iteration 7
View time report for iteration 7.
Iteration 8
Analysis
This was the last week for Andrew to work as a project manager.
This iteration, most of the time was spent on coding. The focus for this iteration was to correct bugs thats been discovered during testing and to update the design according to WCAG. We managed to remove many of the bugs reported in issues and also implemented some features thats been left out earlier in the project.
Andrew added API-routes to the server for changing users details and password while Jimmy added these features to the client. Sofia worked on requirement F13, "Consent email", so now an email is sent to the user after registration with a link that users need to click to verify their email and be able to use the application.
Linda started working on requirement F20, "User account deletion", and updated the design throughout the application according to WCAG. Text, buttons and colors were updated.
Both Sofia and Andrew added tests for newly implemented requirements. Sofia created manual test cases for some of them and Andrew continued writing Postman-tests for the server.
Some documents were also updated before handover to group 0 for peer review. Updates were made to the technical documentation with new diagrams to match changes in the code and instructions for installing, deploying and hosting both server and client was created.
It feels like we succeeded with our goals for this iteration to remove many bugs and clients design looks way better then earlier. For the next iteration, we will continue update the design on client, adding new test cases and try to remove as many bugs as possible before the presentation and final handover to the customer.
Time report iteration 8
View time report for iteration 8.
Iteration 9
Analysis
This was the first week for Jimmy to work as a project manager.
The group didn't spend as much time this week compared to earlier iterations in the project, because some of us decided to focus on another course. A large part of this iteration was spent on documentation. Feedback for construction were given to group 2 and the the wiki was updated to prepare for the final handin and delivery to the customer.
Our goal for this week was to test as many of the requirements as possible from the ones implemented last week and try to solve bugs detected during the testing. Sofia carried out the manual test cases for requirements F5, F6, F7 and F47 and then wrote test reports for them. Issues was created on Github for the failed tests and we also managed to solve some of them. Andrew started to load test the server by using the testing tool JMeter. He also wrote tests for SignalR which differs a bit from earlier testing on the server because SignalR uses WebSockets instead of HTTP to communicate.
Next iteration, we will focus on more testing, preparing the final presentation and complete the documentation needed for the final handin and delivery to the customer.
Time report iteration 9
View time report for iteration 9.
Handover
Handover
Final Customer Delivery
During a meeting with the customer on 20180511 it was decided that final delivery of the RedRiver chat product will take place during week 22. This final delivery will include:
- A copy of the source code
- A downloaded version of the our documentation wiki
The customer also has, and will continue to have, access to the GitHub repo where both the source code and wiki are maintained.
The most current version of our product can be found here
(Test users are available: username: sTestUser{x} password:sTestUser{x} where x runs from 0-9)
We have expressed to the customer that we are willing to answer a certain amount of support questions concerning functionality, implementation etc. should they wish to further develop the product.
Achieved Functionality
In our opinion the project has gone well, without any major setbacks or significant technical problems. Any technical problems which did arise, for example CORS problems within the hosting environment or differing SignalR versions, were dealt with in a timely manner and did not cause undue delay to the project. However, the scale of the project was sizeable from the outset, and we have been candid with the customer as to what we believed was possible within the project's timeframe. In this regard, our predictions were accurate and we have implemented only a part of the total required functionality.
We deliver then a working client-server-database architecture where the user can:
- register (including email verification), login/logout, update details (including avatar), change password
- add/delete friends
- create, join and leave chat groups
- send private (HTTPS) chat messages with chat groups, where no chat messages are stored on the client device.
We also deliver limited video chat functionality.
Our entire product backlog can be found here
Implemented requirements are summarized in the following table:
| Status | Functionality | Usability | Reliability | Perform/e | Support/y | Total |
|---|---|---|---|---|---|---|
| Not implemented | 35 | 1 | 3 | 1 | 1 | 41 |
| Started | 2 | 5 | 5 | 0 | 0 | 12 |
| Implemented | 10 | 0 | 2 | 0 | 0 | 12 |
| Sum | 47 | 6 | 10 | 1 | 1 | 65 |
Further development
We believe that both our code and documentation set a solid ground for further development, both in terms of the available source code and documentation. Going forward, we recommend the following:
- SignalR at present uses an in-memory dictionary to store current connection details. This is fast and suitable for lower volumes of users. Should the number of users increase greatly then this might not to be the best solution; instead the architecture must be scaled out. Documentation concerning this is available here.
- In our project a Microsoft SQL database was used for all purposes. The pros and cons of this should be evaluated against document databases such as MongoDB. Should the decision be made to continue with a relational database, the tables used should be normalised. For example, a user can enter into a friendship with another user; at present this is stored as two entries in a friendship table (one friendship in each direction). Alternatively this might be seen as a single database entry between two users, thereby offering substantial space savings in a system with many users.
- Encryption: Our project featured communication over HTTPS and built in database encryption, and no data is stored on the client device. However, database admins can still see chat logs. End-to-end encryption would solve this problem. Our initial researched that this would be difficult to implement in a browser based system, but some form of partially encrypted logs is fully possible.
- Video chat is available, although it is not fully tested and may not work on all devices. Going forward, this should be further investigated and well-tested so as not to lead to an adverse user experience.
- SendGrid is used for sending verification emails to a newly registered user. For it to work properly after the handover it needs to be set up. How to do that is described here.